Redis is actually a very reliable engine to store data, as long as you keep in mind its design principles. (the Aphyr post is great with that). The replication and cluster modes can add additional complexity (but of course mysql master-slave or master-master have their own risks and complexity as well.)
Just comparing a single box vs single box.. this is about 3,333 queries per second if I understand the metric used (200k req per minute). A Redis instance (non-sharded) can handle 50 times that in a single thread, while maintaining sub-ms latency.
For this volume of data, and given the low queries per second, MySQL is probably a better choice since Redis wouldn’t scale for the cost of RAM. (It would be silly to pay for that RAM if SSD or spinning disk can handle the load.)
Redis is really nice when used in conjunction with other servers. At Userify (SSH key management for cloud instances), we used to function with a purely MySQL environment, but MySQL couldn’t keep up with our requirements (tens of thousands of qps) on low-end hardware for mostly small bits of data. We converted the whole thing to Redis + S3 and are scaling very smoothly, even though we actually encrypt and gzip data before writing to Redis (and we actually write-through to S3, which is mostly invisible except for sequentially pipelined operations). There are circumstances where we could have the lost-write problem, but they are rare in practice and would basically be the same effect as rolling-back a commit.
If I was going to scale the WiX model higher, I’d probably keep MySQL for the blob data (or use S3) and use Redis for lookups, or pursue other paths to keep MySQL in place (or perhaps pgsql). But don’t fix it if it ain’t broke.
And, of course, there is still a very long way you can go to take MySQL (or Postgres) to insane heights (just ask Facebook), including NDB/MySQL Cluster, innovative caching solutions with Redis front-ending MySQL (the way you used to do with Memcached), maxscale, or additional sharding.
In other words, your design works and works well, and shows the power of MySQL (or especially Postgresql) as a general purpose data store. I really agree that you should always start on the datastore that you think you can get up and running with the fastest (although Redis is just a dream to work with — unlike, say, Cassandra!), and focus on optimization later, because optimization is always possible later within any complex system.
Read more here: https://news.ycombinator.com/item?id=10708782
jamiesonbecker comments on "MySQL is a Better NoSQL"
No comments:
Post a Comment