Concurrency Improvements in TokuDB v6.6 (Part 1)

With TokuDB v6.6 out now, I’m excited to present one of my favorite enhancements: concurrency within a single index. Previously, while there could be many SQL transactions in-flight at any given moment, operations inside a single index were fairly serialized. We’ve been working on concurrency for a few versions, and things have been getting a lot better over time. Today I’ll talk about what to expect from v6.6. Next time, we’ll see why.

Summary of Results

Running multiple iiBench clients on a single MySQL instance, we see a big improvement in the cumulative insertion speed at all concurrency levels. We see a gain of 33.9% in single-threaded performance and 51.8% at 64 threads.

If we add a thread doing queries into the iiBench tables, the insertion threads maintain much higher throughput than they previously could. We see a gain of 97.5% in single-threaded performance and 45.8% at 64 threads, in the presence of this query thread.

Also, the query thread’s performance improves a bit in v6.6.

Generally, the behavior you’ll see in TokuDB v6.6 is this:

1. Queries with no writers are extremely concurrent.
2. Queries are very concurrent with writers in different regions of the key space.

   • Queries and writers in the same region of key space are often somewhat concurrent anyway.

3. Writers in different areas of the key space are very concurrent.

   • Writers in the same area of the key space (e.g. multiple sequential insertion threads) are not very concurrent, but the aggregate performance of all threads should be comparable to or even a bit better than the performance of a single thread.

In Part 2, I’ll talk about how we made this happen from an engineering perspective, and why you can expect these performance characteristics.