Modernizing an IBM DB2 Stack With Tarantool: Top 4 Questions Answered

Like React or Go, Tarantool is an open-source project backed by one of the world’s largest internet companies. Since its initial release in 2008, Tarantool has been continuously improved in a “real-world laboratory” under heavy workloads.

Unique among the current in-memory database offerings, Tarantool operates as fast as a cache database but has been engineered to maintain relational-style properties, such as fully ACID transactions and complex queries. In fact, its relational properties are strong enough that it can be used as a primary database.

Tarantool’s other uncommon feature is its Lua-scriptable application server, which runs alongside its DBMS and opens up the whole world of Lua functionality to Tarantool data. Tarantool completely supports SQL statements and conforms to the SQL:2016 standard.

1. How Can Tarantool Quickly Improve My DB2 Implementation?

One of Tarantool’s most straightforward and effective uses is as a replicator in an existing Relational Database Management System (RDBMS).

With its low-overhead, lock-free architecture, Tarantool can process many more queries per core than a traditional relational database like IBM DB2. This means it can cheaply take over workloads from expensive enterprise DB2 Servers.

This allows a stack to become lean, and also makes it less expensive to scale — particularly because Tarantool can be run on commodity hardware. Enterprises have had great results trimming their stacks with Tarantool.

Let’s take the internet dating site Mamba. They reported shedding seven servers after adding Tarantool to an existing implementation. Cutting down on servers saves on licensing in addition to hardware.

Tarantool can also be used to facilitate a DB2 stack’s refactoring into a microservices-style architecture. Tarantool’s design is perfect for microservices as it can be run as multiple independent instances, each potentially with its own data store (the largest known number of simultaneous Tarantool instances is around 500).

Tarantool could, for example, completely take over authentication for a web application, operating completely without “relational backup.” Because of Tarantool’s application server functionality, individual instances can both serve data and call in data from outside sources, such as from REST APIs.

2. How Does Tarantool Replicate From DB2?

Tarantool partners with data industry leaders like Informatica and Continuent to enable replication, which works by reading logs.

3. How Does Tarantool Compare to DB2’s Existing In-Memory Solution, BLU Acceleration?

BLU is a “retrofit” to an existing relational system, not an in-memory engine designed from the ground up like Tarantool. BLU uses a columnar structure, which is great for queries over all data, i.e. OLAP-type operations, but it is not intended for index-based transactions that process less than 100 rows per commit, i.e. OLTP-type operations. In comparison, Tarantool can accelerate DB2 data to perform OLAP-type operations while simultaneously allowing OLTP with its fully ACID transactions.

Additionally, BLU has heavy hardware requirements, which is not surprising given that it is effectively an add-on to expensive enterprise-grade servers. IBM recommends at least eight cores and 64-128 GB of RAM to run BLU. In comparison, Tarantool can execute one million transactions per second on an AWS t2.micro instance that has only 1 GB of RAM.

The above being said, Tarantool could potentially be used in conjunction with BLU, particularly in a microservices architecture.

4. Can Tarantool Manage Data From Other Sources at the Same Time as DB2?

Due to its SQL capability, Tarantool can read data from MySQL, Oracle, Microsoft SQL Server, PostgreSQL, and others.

It can work with multiple data sources simultaneously, federating data for ultimate presentation to front-end solutions such as QlikView, Cognos, or Tableau. Tarantool can also import partial tables in many cases, assembling data to eliminate expensive joins. It is faster to federate data in Tarantool and present it to BI tools than it is to bring that data directly to the BI tools.

Conclusion

Because RAM prices have steadily decreased over time, in-memory databases are a technology whose time has come.

Tarantool’s ability to conform to and enable myriad application architectures allows DB2 stacks to easily and cost-effectively take a step in this future direction.

Do you have more questions about your project? Visit the Tarantool Challenge to connect with actual developers for answers.