This is an English translation of a post by Leonid Yuriev, originally published on Facebook here: https://www.facebook.com/leo.yuriev/posts/553318381522430?pnref=story.
The post is about Leonid’s experience of using both Tarantool and Redis. This is only the beginning. More articles are on the way. So let’s start :-)
As a part of my work, I have compared Tarantool and Redis from Redis Labs.
Here are some intermediate results.
- Dev team availability
Kostja Osipov and the guys from Tarantool’s team are always available.
2. Support of Lua
To make the long story short, Tarantool is a real Lua application server, whilst Redis can just run Lua functions only with local variables.
- Tarantool has a full-feature Lua engine with JIT, which is integrated with the database and has embedded fiber support.
- For the majority of blocking libc functions, Tarantool’s Lua implementation has counterparts that switch fibers.
- You can write and run a full-feature service that can use any Lua libraries, use network, get and process internal requests, connect to external services.
- Stored procedures and triggers just exist and work as they should,including the fact that you can write them in C and load them as shared libraries.
- You can easily update/reload all Lua functions without even having to restart the server.
- Lua interpreter lives aside in a sandbox and is good only for simple scripting (only pure functions and only local variables).
- You can complete a script by EVAL or load and start it later by EVALSHA.
- Redis itself is available from a script only via a local connector.
- In last versions of Redis you can write modules/plugins on C.
Redis is focused on in-memory processing with a possibility to back up data periodically or on stop. On the other hand, Tarantool can continuously persist data on disk.
Tarantool: besides snapshots, it has a full-scale WAL (write ahead log). So it can secure data persistency after each transaction out-of-the-box.
Redis: in fact, it has snapshots only. Technically, you have AOF (append-only file, where all the operations are written), but it requires manual control over it, including manual restore after reboot. Simply put, with Redis you need to manually suspend the server now and then, make snapshots and archive AOF.
4. Latency and throughput
In Tarantool, you have dedicated threads to handle networking and writing to disk. That’s why you have better latency in real-life cases. But in synthetic tests, Redis should have better throughput because there is no CPU usage on context switching and thread synchronization.
Tarantool has secondary indexes, including Geospatial Indexes (R-TREE).
Redis does not have secondary indexes, but you can simulate them with several operations or by Lua scripts. Sometimes it looks gross. See details here: http://redis.io/topics/indexes
6. External API
Redis has simple interfaces for basic data structures like lists, sets, hash tables. Those interface methods are based on the concept of accessing an object/structure via network, which is intuitive for most people.
Tarantool has a more general interface for data manipulation, which supports all the functionality above.
7. Clusterization and replication
Redis has ready-to-use Sentinel with replication and failover.
Tarantool has replication, including master-master, but there is no intrinsic orchestration of a cluster or native failover (Tarantool developers say that this is in progress).
8. Database size
Tarantool has a brand-new storage engine named “vinyl” (it is not officially released, but you can already try it). It allows you to store and process data which does not fit in your RAM.
Redis only has an in-memory engine and nothing more in plans by now.
Tarantool: SQL support is coming soon (based on a fork of sqlite), including ODBC/JDBC. Select operations have already been implemented. You can try them.
Redis: No SQL support at the moment and not even in plans.
If you aspire for absolute objectivism, then you should know that the comparison above contains some inaccuracies.
However, attempts to eliminate them will require a huge number of details that cannot be objectively compared.
Thank you for reading. If you want to add something on top of what’s been said above or clarify it, feel free to leave a comment.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!