4 ms·

> 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) o

> 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.

nostrademons 15y ago
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?
- brown9-2 15y ago
  This same argument applies to storing your relational data in a server separate from the app server, doesn't it?
  - nostrademons 15y ago
    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.
    - deleted 15y ago
      [deleted]
    - Detrus 15y ago
      You're depending on each language's data structure implementation there. Redis aims to be more efficient than those.

nostrademons 15y ago

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?

brown9-2 15y ago
This same argument applies to storing your relational data in a server separate from the app server, doesn't it?
- nostrademons 15y ago
  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.
  - deleted 15y ago
    [deleted]
  - Detrus 15y ago
    You're depending on each language's data structure implementation there. Redis aims to be more efficient than those.