Our First Database, a Basic In-Memory Key/Value Store

Posted by Matt Hagy on April 15, 2020.

We have developed our first database, a Basic In-Memory Key/Value Store. While simple, it has some similarities to actual production in-memory key/value stores such as Redis. Further, it does correctly implement concurrent read and write requests through multi-threading with locking.

In the project, benchmarking is performed and we find that read heavy workloads do significantly benefit from multi-threading while write heavy workloads only get a modest boost in total performance. You can find more details in the project write up, including a discussion of why this may be the case.

Impact of threading for ConcurrentHashMap with a large key space

One thing that I find particularly surprising is that Hashtable has similar performance as ConcurrentHashMap in all of the tested scenarios.

Summary of benchmarking results

As discussed in the project, it is generally thought that ConcurrentHashMap is superior due using an internal structure composed of multiple distinct segments, each with their own lock. In contrast Hashtable just has a single global lock. Further, ConcurrentHashMap is developed to allow lock-less read operations, including get(key). In the project write up write up we consider why these two Map implementations may demonstrate similar performance.

I found this project quite enjoyable to develop and I learned more than I expected. I hope that you too can learn something from it also. Next, we're going to develop a disk-backed key/value store to provide actual persistence. This will introduce some new challenges and I'm quite excited to solve them. I hope to have that finished in the next week so check back soon.