Re:The Great Redis Misapprehension
by nostrademons on Sunday November 27, 2011 @10:23PM
(#3284332)
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?
[ Parent
| on HN ]
This same argument applies to storing your relational data in a server separate from the app server, doesn't it?
Re:The Great Redis Misapprehension
by nostrademons on Sunday November 27, 2011 @10:35PM
(#3284365)
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.