6 ms·
This is very cool. But why didn't they just go with Redis? Their blog stated that this requirement: "be very fast even with millions of entries" wasn't met by
by shepardrtc 7y ago
This is very cool. But why didn't they just go with Redis? Their blog stated that this requirement: "be very fast even with millions of entries" wasn't met by Redis, but I have a very hard time believing that.
- Eikon 7y agoThere’s no network latency involved as it’s an in memory, embedded database. Also, max throughput here is ultimately a sum of how fast the memory allocator is and memory bandwidth which, even with a poor implementation would be orders of magnitude more than what you can do with standard NICs and Linux kernel networking stack. Moreover, as a consequence, far less context switching is involved.
- Znafon 7y agoI thought it was possible to embed Redis.
- Eikon 7y agoPossible don’t mean ubiquitous. You get no support and plenty headaches when you start to do that sort of weird, unsupported things with a product.
- shepardrtc 7y agoAhh I missed the part about the network. That makes much more sense, then.
- Exuma 7y agoCan you explain why redis require extra network time?
- shepardrtc 7y agoIts just time to transfer across the network, whereas this project is in-memory with the program that's calling it.
- stevekemp 7y agoThey do discount networked solutions, but then talk about making HTTP-calls with JSON payloads. Or was that just for testing?
- harshvladha 7y agothey mentioned in the introduction only. "we decided to give up external caches like Redis, Memcached or Couchbase mainly because of additional time needed on the network" reason: additional time needed on the network. there are many scenarios in which you will want to consider in-mem cache of the application, one scenario is very low latency requirements.
- dingribanda 7y agoPer the article, Redis requires a network call to the redis server. They wanted an in memory cache. Not sure how would you keep the per machine in memory cache in synch without change propagation to all the machines. This looks like a simple TTL cache.
- tobz 7y agoAgreed. Others have mentioned that the article calls out ignoring traditional in-memory cache daemons because of the additional network time, but with a targeted p50 response time (of their HTTP service fronting all of this), and caches like Redis and memcached being able to respond in hundreds of microseconds... it does feel like they didn't actually run the numbers. The other natural alternative would simply be to run Redis/memcached and colocate this HTTP service on the same box. Now your "network latency" component is almost entirely negligible, and you've deferred the work of managing memory to applications _designed_ around doing so.
- KirinDave 7y agoBecause Redis is... problematic? 1. Redis has a lot of functionality that a simple cache client doesn't need. 2. Redis's connection model can lead to complications. 3. Redis's to-disk checkpointing in practice uses a lot of memory. 4. Redis's poorly chosen default settings have cost the industry an uncounted but large sum of money. 5. Redis is written in C. That's a bad idea for a networked application. 6. Redis's creator is a person who doesn't deserve our support. He's constantly combative with experts who have give him good advice about how to improve Redis because he has a vision of "simplicity" which translates to "what I already understand." Redis is a decent choice if you need all of its features. It's got a wide spectrum. But, if you don't need ALL of them, then pick a simpler and better designed system.
- sagichmal 7y ago> Redis's creator is a person who doesn't deserve our support. There are valid criticisms of Redis but this is shitty and vindictive. You should be ashamed.
- KirinDave 7y agoI'm neither vindictive nor ashamed that I am pointing out Antirez argued passionately and publicly for the right to say "master and slave is a term of art and I will keep using it." I'm also not ashamed of pointing out that Redis as a project is famous for hand waving away redis problems.