Tarantool vs. Redis: In-Memory Databases Face Off

With respect to in-memory databases, Redis improved upon Memcached with the abilities it introduced to persist cached data, to use data types other than strings, and to perform complex operations on data. [1]

Tarantool improves upon Redis by taking the operations that can be performed on data sets to a whole new level of sophistication—as well as surpassing Redis in terms of persistence and indexing, not to mention speed and support. [2] In fact, given the high quality of Tarantool’s persistence processes, as well as its facility for transactions and large data sets, it can effectively be used as an application’s sole database—a feat that is frankly not often accomplished with Redis. [3]

A chief limitation of Redis is that it can’t process a data set larger than the RAM of its server, as per the FAQ on its website: “...we are very happy if we can do one thing well: data served from memory, disk used for storage.” Tarantool offers a choice of storage engines: Memtx, which functions like a traditional in-memory database, and also Vinyl/Disk, which allows the use of disk storage in conjunction with RAM. Vinyl provides the ability to work with data sets that are 10 to 100 times the size of available RAM. [4] It is able to work with these large sets because it is optimized for fast random writes, the main bottleneck that arises with this configuration.

Technically speaking, Vinyl implements a disk-access algorithm called log-structured merge tree, or LSM, instead of the more common B-tree. [5]

Redis and Tarantool can both be scripted using variants of Lua, thus allowing complex functions to be performed on data sets. And in addition to this custom Lua scripting, both Redis and Tarantool can be augmented with certain packages from the LuaRocks ecosystem. However, right out of the box, Tarantool uses the faster LuaJIT as opposed to the vanilla Lua implementation of Redis. Not only that, but Tarantool runs a full, non-blocking Lua application server that has access to network and external services. Conversely, Redis’s Lua implementation is sandboxed and its scripts are blocking. [6] In other words, waiting for Lua processes to complete in Redis can cause performance issues that don’t exist at all in Tarantool.

Of course, a comparison of Tarantool and Redis would be remiss without at least a brief mention of their relative throughput and latency numbers. Tests for them on a single node, using the Yahoo! Cloud Server Benchmark’s (YCSB) six core workload types—“update heavy,” “read mostly,” “read only,” “read latest,” “short ranges,” and “read-modify-write”—show that Tarantool, with both hash and tree indices, respectively, has better throughput than Redis on all workloads. Tarantool has lower latency with many workload types, and although they are nearly always close, Redis does have lower latency with some. This includes workloads both with and without write-ahead logging, a persistence feature.

Tarantool’s ultimate advantage over Redis lies in the fact that in tandem with a database management system (DBMS), Tarantool runs a full application server. [7] This server, which can also be run alone, rolls out a whole additional suite of technical tools that Redis just doesn’t have at all. The “killer function” of Tarantool’s application server is its ability to work in conjunction with, and thus accelerate, any number of slower, legacy databases—including Oracle, IBM DB2, MySQL, MS SQL Server, and PostgreSQL.

Tarantool orchestrates and virtualizes the data of its targets, enabling data to be accessed more rapidly. Adding Tarantool into the architecture of nearly any enterprise application or service lightens code bases for integration and scale, and also reduces servers and hardware requirements. For example, one Tarantool server can replace potentially dozens of servers running a traditional DBMS—allowing you to rapidly scale your microservices and applications. [8]

References

1 http://www.infoworld.com/article/3063161/application-development/why-redis-beats-memcached-for-caching.html

2 https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc

3 https://news.ycombinator.com/item?id=3010345

4 https://medium.com/@denisanikin/tarantool-vinyl-200k-transactions-per-second-on-a-disk-based-database-c5f3cbb a6543

5 https://medium.com/@denisanikin/when-and-why-i-use-an-in-memory-database-or-a-traditional-database-manage ment-system-5737f6d406b5

6 https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc

7 https://medium.com/tarantool-database/dbms-as-an-application-server-779402dbf485

8 https://medium.com/@denisanikin/how-to-save-one-million-dollars-on-databases-with-tarantool-5eb1596ec628