I think a few more concrete use cases would help.<p>First, a key limitation that every architect should pay attention. Redis reaches the limits of what you can do in well-written single-threaded C. One of those limits is that you really, <i>really</i>, *really* don't want to go outside of RAM. Think about what is stored, and be sure not to waste space. (It is surprisingly easy to leak memory.)<p>Second, another use case. Replication in Redis is cheap. If your data is small and latency is a concern (eg happened to me with an adserver), then you can locate read-only Redis replicas everywhere. The speed of querying off of your local machine is not to be underestimated.<p>And third, it is worth spending time mastering Redis data structures. For example suppose you have a dynamic leaderboard for an active game. A Redis sorted set will happily let you instantly display any page of that leaderboard, live, with 10 million players and tens of thousands of updates per second. There are a lot of features like that which will be just perfect for the right scenario.
At desktop resolution, the floating table of contents menu blocks out two of the (excellent) illustrations (second and second-last). Deleting aside.toc was very helpful.
> Send 1KB over a 1GBps network<p>This is said to have a 10μs latency in the chart. But I'm fairly sure that is a calculation of bandwidth based on 1KB / 1GBps<p>10μs is about 3Km, so at most a 1.5Km round-trip.<p>For a chart labelled latency, I'm surprised to see bandwidth calculations included. Any network hop would actually have far greater latency, if nothing else because communication typically involves more than a single round-trip for acknowledgement, etc.<p>It might be worth making it clear some of the numbers are about bandwidth not latency.
A question so noob I'm almost shy to ask it:<p>The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?
Really love this style of writing. Pairing the diagrams/illustrations with the easy to grok copy is really helpful for folks like myself who have been mainly focused on the front-end.<p>What tool do you use for your diagramming, is it all hand-drawn?
I'm not too familiar with redis and this may well help, so thank you.<p>I see some data-types on the right. It surprises me that redis doesn't have a numeric data type. I understand that at its heart it is just a key-value store and doesn't ever need to do range-based lookup but it still surprises me.<p>One consequence of "everything is a string" I've run into (although probably a sign I'm "doing it wrong"), is serialisation overhead in the client.<p>If redis is expecting strings then it's left to the client to choose an appropriate serialisation which can have either performance or other pitfalls.
As someone who doesn't code for a living but teaches it to mostly novices, this helps (because before this I had no clue what it was except that it had something to do with databases.) Typically for my courses we just use some flavor of SQL and call it a day (and that kind of spoils us because of how declarative it tends to be) -- roughly, what's the "explain like I'm 10" use case for Redis over something else? From what I'm seeing, it's mostly an "efficiency" thing?
This is great, the visual explanations work really well<p>One thing that threw me off is that it says for an SSD a random read is 150μs, but 1MB sequential read is 1ms? Shouldn't sequential reads be faster, or are two different read sizes being compared or something? If so, the ambiguity may confuse some people to think random reads are faster
Very informative and love the illustrations.<p>I'm building a new website and am using sidekiq for background job processing which relies on redis behind the scenes to store all the job data. I configured a high availability redis instance with `maxmemory-policy noeviction` to ensure no data is lost.<p>The website is still in its infancy so not thinking about scale for the next little while but curious if you have any tips or gotchas to keep an eye out for. Thanks!
I am thinking of using Redis as a lightweight queuing mechanism. An event source will MULTI a small amount of metadata as a hash and append a list. Event sinks will BLPOP the list and retrieve and delete the metadata key. One requirement is the events survive power loss.<p>Is there anything inherently wrong with this? Gotchas? A mockup I've done works great so far.
I've been looking into tech stacks to make a collaborative editor and Redis CRDTs come up a lot. IIUC this requires a Redis db running in each users machine and they connect P2P with each other. Do I understand right? Anyone have good resources for this? I've also seen Riak come up as an alternative. Do they work similarly?
The only person stand out to witness a use case is a adserverer, I read the 1st 100lines of comments.
It is like california highway system particularly when I witnessed, the billboard is very outstanding. The jams an pits, people are very nice to them.
Very interesting.<p>This is leading me to think, using redis as the sole database is very tempting but the Ram requirement is making me think twice.<p>Wouldn’t there be a database like redis that only stores the latest data into memory and keeps the rest in an AOF file ?
It's not clear to me why it makes sense to use both RDB Files and AOF on the same Redis instance. Seems like AOF would always be the more accurate source of truth here. What am I missing?<p>Great article though!
The white cube in the traditional usage example - what does that represent? App code? Or so that cache miss to db implemented in some standardized way?
It's a good article, but a couple of hopefully constructive points<p>1, .toc-wrap covers the image on desktop<p>2, the image is way too busy, there's too much going on