Dolt is the world’s first version-controlled database aimed as a drop-in replacement for MySQL. Over the years, we’ve made huge improvements to our performance metrics, even surpassing MySQL in many benchmarks. However, TPC-C is one where there is still a somewhat large performance disparity between Dolt and MySQL. Today, we bring you Lazy Flush, an improvement to our materialization logic that gives a ~25% increase in Transactions Per Second (TPS).

The Problem#

TPC-C is an industry standard performance benchmark for OLTP databases that attempts to simulate real-world usage of an OLTP database. The benchmark will randomly select from a few different transaction types that each read and write to various tables. Each transaction will BEGIN a transaction, run a few reads (SELECT statements) and writes (INSERT, UPDATE, DELETE statements), and lastly COMMIT the results. If you’d like to learn more about the details of TPC-C, you can read this blog.

Within a transaction, modifications to tables are visible to readers/writers within that same transaction and are not persisted until COMMIT (or discarded on ROLLBACK). Dolt handles this by reading from the current RootValue and always immediately materializing the results to a new RootValue. This solution is nice because it is relatively simple; we can always rely on the current RootValue to have the most up-to-date version of the table. The problem is that the cost of materializing every edit to a new RootValue every time can add up, especially when there are multiple edits that may be discarded.

The Solution#

The solution is to just not do that; we don’t need to materialize the edits every time. Table writers already put changes in a MutableMap, which is an in-memory skiplist representation of the table. It is entirely possible to leave the edits in the skiplist and continue to read/write from that MutableMap until we commit the transaction. Essentially, we are delaying flushing the edits from the current transaction to the RootValue until it is necessary, and we rely on the MutableMap stored within the writers as our most up-to-date table. We call this Lazy Flush.

Performance Improvements#

With Lazy Flush, we’re seeing TPS increase from 56.93 to 71.37; that’s a 25.36% more transactions every second! For reference, MySQL can do 96.79 TPS, so we’re unfortunately still 1.36x slower than MySQL.

Additionally, we’re seeing a performance win in our Sysbench write benchmarks. There’s a 8.58% improvement in oltp_read_write and 16.5% in oltp_write_only. As a result, every write benchmark is faster than MySQL…except for oltp_read_write, which is about 5% slower. The updated full benchmarks are available on our docs.

Conclusion#

The Dolt performance journey continues as we continue to close to gap on MySQL benchmarks. If you find any performance issues with Dolt, feel free to report it on Github Issues or discuss with a team member on our Discord.