Hacker News Reader

Comment by nostrademons | Hacker News Reader

I'm curious why you would use Redis instead of just using in-memory datastructures in your app servers? It's trivially easy to implement a leaderboard as a priority queue, for example. And it eliminates the need to run yet another server and deal with the associated RPC & command parsing overhead.

That's the approach Hacker News and Viaweb took, along with Mailinator and probably several other startups.

View on HN

I'm curious why you would use Redis instead of just using in-memory datastructures in your app servers?

I make fairly pedestrian use of Redis, generally as either a persistent cache, shared memory, or schemaless DB shared by multiple Rails processes. In-memory structures have a lot to anti-recommend them in the Rails world: at any given time I have 4 server processes and 2 worker processes running, and each of them would need a separate copy of everything. There would be consistency problems. Those processes have a lifetime measured in days in the best of cases to minutes in the worst of cases: following a restart, any in-memory structures have to be rebuilt from the underlying data source. Hypothetically assuming demand for my products explodes and I can no longer deal with only a single physical server, Redis plays very well with being accessed from multiple servers, whereas I'd have to write some sort of REST API to reimplement Redis (poorly) on top of my actual people-pay-money-for-this application code to share that state among multiple physical servers, if I were to go down that route.

Redis has been an absolute dream to administrate: the total overhead for me was "apt-get install redis-server", adding three lines of configuration to Rails and tweaking two in Redis, and doing one SCP command when I migrated servers. The RPC/command parsing overhead is, empirically, negligible in my use cases. Don't take this advice if you're Google (I know you're Google, but for the general "you" here), but many people are not Google.

Ah, I was kinda assuming that there's already a separate appserver tier distinct from the webservers. If you don't have that, I can see how something like Redis might be a useful intermediate step so you don't have to go build one until there's actually a substantive need for it.

It's kinda like a complement to memcached then, right? Memcached gives you an off-the-shelf distributed hashtable that you can stick things in. Redis gives you an off-the-shelf list or heap server that you can stick things in. You might eventually want more control of the algorithms that you can run on these, but if it's not yet worth setting up a separate server, you can glue these components together and get a decent approximation.

Ah, I was kinda assuming that there's already a separate appserver tier distinct from the webservers.

That's kinda an enterprise-y architecture choice in my experience. There's excellent reasons for it (much like Service Oriented Architecture) but I generally see folks evolve into it over time rather than starting from it, unless they come from an enterprise-y background where its assumed from the beginning. In particular, Rails and some other opinionated frameworks start from the assumption that 99%+ of the business logic is going to get executed in the web tier, and while I'll bet you that some of the more famous Rails deployments eventually move away from that, Rails would fight you every step of the way if you were trying to do it in greenfield development.

Redis makes a great complement (or drop-in replacement depending on use case) for memcached. Relatedly, I love how these (and other OSS tools) let little guys play with big boy solutions without having to have big boy budgets or organizational resources to make use of them. I think Facebook probably has about 10 terabytes more memcached than I do, but it turns out that memcached is really freaking useful way down the scaling/complexity curve, too.

Redis and memcached aren't really that similar. Memcached is a key-value cache; it will evict items that haven't been used recently, and it has no persistence. Redis actually makes a serious effort to not silently lose data. (Unless you tell it to.)

> why you would use Redis instead of just using in-memory datastructures in your app servers?

If you mean actually storing the data (scores on a leaderboard) on the app servers, the problem is it can only scale so far. If data/state is stored on app servers you can't load balance across multiple servers. HN runs on one server, and it has been hitting scalability issues lately. It's also harder to do high-availability, if everything runs on one server there's nothing to fail-over to.

Wouldn't this apply to a Redis deployment as well? At the point where the app server would fall over, the Redis instance is probably getting just about saturated as well. (Well, perhaps a bit later because Redis is written in optimized C instead of Python/Java/Scala, but still no more than a constant factor away.) So you'd need multiple Redis instances. How is coherency between them handled? Does the client library automatically take care of synchronizing writes to multiple instances and failing over reads, or do you have to do all that yourself?

This same argument applies to storing your relational data in a server separate from the app server, doesn't it?

The difference is that relational data is usually disk-based, I/O bound, and requires persistence but not necessarily fast access. There're a bunch of algorithms that are specialized for the access patterns of disks (who wants to implement their own B-trees and transaction logs, other than Google?), so it makes sense to use an off-the-shelf solution for them.

Redis's main selling point is being an in memory datastore, which is great. But virtually every programming language has a rich selection of in-memory data structures in its standard library, along with the ability to write code and implement some more. What is it that Redis gives you over using these? Programmers are generally quite familiar with efficient algorithms for accessing memory - it tends to be taught in intro CS.

You're depending on each language's data structure implementation there. Redis aims to be more efficient than those.

Do you know how Hacker News persists changes to its in-memory data structures? Does it snapshot every few seconds or journal every change? Does it keep comments in memory or swap them as needed?

The idea is that you coordinate concurrent read/write to the same structures, yielding a shared data view without formal coordination. Also, the structures may be large enough that you don't want them all in-memory for each client.

I was kinda assuming that the system already has a separate appserver tier from the webserver tier (HN doesn't, but many other real-world apps would). Separating application logic from HTML formatting is usually a good idea, if only because HTML templating tends to be CPU-intensive but memory-light while application logic is often CPU-light but memory-intensive. That's an orthogonal issue, though - you can run as many appserver instances as are necessary for your dataset.

I guess I was wondering why, in your app server, you don't just add a big in-process heap and use the normal language mechanisms to access it wherever you'd return your leaderboard info?

The concurrency issue is interesting - how does Redis handle it? Does it have some sort of STM, or is it all because everything executes in a single thread in Redis? If it's the latter, you'd get that for free in a single-threaded appserver (although you probably don't want a single-threaded appserver).

Redis is single-threaded. Also, not everyone uses stateful app servers.

For one thing: stability, which brings you sleep at night

I use redis a lot to store non critical data. For instance I store signup confirmation tokens in redis. The web app sends a message to RabbitMQ when a user signs up, then a background worker catches that message, creates an activation token, stores it in redis, and sends an email to the user. You can set an expiration time on keys too. It's convenient shared memory.

Reply on news.ycombinator.com