Next-Level MySQL Performance: Tarantool as a Replica

Refactoring your MySQL stack by adding an in-memory NoSQL solution can improve throughput, allow scalability, and result in substantial hardware savings.

Tarantool is particularly suited as a MySQL addition, as it offers all of the speed of the basic cache databases while maintaining many features of a traditional Relational Database Management System (RDBMS).

For example, Tarantool has fully ACID transactions — including rollbacks — as well as secondary indexes and Lua-scripted stored procedures. Unlike Memcached or Redis, which can only be queried by key/value pairs, Tarantool’s data objects accommodate the use of relational-style queries, which can be written in Lua or SQL (or the two mixed together).

To illustrate Tarantool’s ability to accelerate a relational stack by replicating it, consider the raw speed differential between Tarantool and a relational counterpart. Tarantool can execute one million queries per second on a single core, whereas this feat would require anywhere from 20 to 722 cores on a relational database.

Offloading work to Tarantool’s low-overhead and lock-free architecture allows existing relational implementations to become considerably leaner — at least this is what Mamba, a large internet company, experienced: they eliminated seven servers by adding Tarantool to their MySQL stack.

Tarantool’s replication of an existing MySQL installation can take two approaches:

1. It can be added to a more traditional type installation, perhaps where an original single node was replicated and sharded.
2. It can be used to modernize and transition to a microservices architecture. In this installation, multiple small processes each have their own functions and data sources. Microservices are a natural fit for Tarantool because it can be run as multiple instances. The maximum known instance number of Tarantool processes is around 500.

Connection to MySQL is based on libslave and it works by reading MySQL’s binary logs. A simple configuration file specifies which databases and tables should be replicated. Whole tables need not be used, as Tarantool allows the replication of subsets of tables — i.e. fields. Data can also be put into one “space,” eliminating the need for joins between tables. With regards to monitoring, there is a separate space in Tarantool that shows a running status of the replication, which is similar toSHOW SLAVE STATUS in MySQL.

Because Tarantool features a fully scriptable Lua application server in addition to a database management system, it can serve as the “glue” between MySQL and the whole ecosystem of Lua functionality, including LuaRocks modules. Unlike the Lua implementation in Redis, Tarantool’s application server has full access to network and external services. Using the application server, it is possible, for example, to automatically remove old data from the database(s), to send an HTTP request, or to save data to the database(s). Data can even be directly served out of the database(s) via a REST API.

When added to a MySQL stack, Tarantool’s data-processing capabilities allow the stack to be downsized considerably as well as reorganized — potentially into a microservices architecture. Tarantool also greatly expands the functionality of MySQL, to the degree that a sizable amount of backend code in an application can be eliminated. To learn more, please contact us directly.