Memcached: All content tagged as Memcached in NoSQL databases and polyglot persistence
Mail.ru, one of the most popular Russian web sites, has open sourced ☞ Tarantool which among other components includes also (another) in-memory key-value store.
From the ☞ project home:
- The system is optimized for work with large volumes of data;
- Tarantool uses snapshot files, which contain the state of the database at the time of copy to disk;
- Transaction logging in binary log files preserves all changes to database state, allowing automatic restoration of information after system reboot;
- The system provides high availability, automatic switchover to an available replica in case of crash of any part of the system;
- The system is fully compatible with the memcached protocol;
- Local replicas allow system update without interruption to client services;
- The system provides data replication over the network;
- Tarantool supplies a simply binary protocol for replication, supporting the creation of additional logic.
It sounds like an improved, HA memcached, which would place it close to products like Membase
- Details about Tarantool are still scarce, so I’m not 100% about it. (↩)
Original title and link: Tarantool/Silverbox: Another In-Memory Key-Value Store from Mail.Ru (NoSQL databases © myNoSQL)
A long and interesting discussion on comparing Redis and Memcached performance. It all started ☞ here:
After crunching all of these numbers and screwing around with the annoying intricacies of OpenOffice, I’m giving Redis a big thumbs down. My initial sexual arousal from the feature list is long gone. Granted, Redis might have its place in a large architecture, but certainly not a replacement to memcache. When your site is hammering 20,000 keys per second and memcache latency is heavily dependent on delivery times, it makes no business sense to transparently drop in Redis. The features are neat, and the extra data structures could be used to offload more RDBMS activity… but 20% is just too much to gamble on the heart of your architecture.
Salvatore Sanfilippo ☞ followed up:
[…] this is why the sys/toilet benchmark is ill conceived.
- All the tests are run using a single client into a busy loop.
- when you run single clients benchmarks what you are metering actually is, also: the round trip time between the client and the server, and all the other kind of latencies involved, and of course, the speed of the client library implementation.
- The test was performed with very different client libraries
But he also published a new benchmark. And Dormando ☞ published an update picking on the previous two:
The “toilet” bench and antirez’s benches both share a common issue; they’re busy-looping a single client process against a single daemon server. The antirez benchmark is written much better than the original one; it tries to be asyncronous and is much more efficient.
And it didn’t stop here, as Salvatore felt ☞ something was still missing:
The test performed by @dormando was missing an interesting benchmark, that is, given that Redis is single threaded, what happens if I run an instance of Redis per core?
I assume everyone is asking by now: which one of Redis and Memcached performed better? And the answer is: it depends (even if some would like to believe differently).
But why is this the “answer”? Firstly, because creating good benchmarks is really difficult. Most of the benchmarks are focusing on the wrong thing or they are covering not very real-life like problems.
This would be my very simple advise:
- basic benchmarks will not give you real answers
- you are better testing for your very specific scenario (data size, concurrency level,