Garnet is a cache server from Microsoft.
Why? A lot of modern-day applications use a cache layer like Redis and Memcached as a way to reduce load on the operational database. While initially a key-value cache with good in-memory performance, Redis evolved into a "cache server" that supports many different kinds of data structures, not just a dictionary/key-value store. For example, Redis lets you use Heaps, Queues, and many other additional data structures. The problem with this is that these need to be implemented in pure C within the redis codebase, not really allowing for a lot of flexibility in the types of auxiliary data structures that the cache can handle.
There are a lot of other reasons to not use Redis too. Performance is one (is it?) and there are many, many other alternatives like DragonflyDB etc. The RESP is also super popular, and a lot of applications and clients speak it; it would be wise to capitalize on that.
Garnet does a bunch of new things:
- pluggable and completely configurable userspace networking layer: the networking layer operates independently from the cache implementation, allowing users to swap out to whatever networking implementation they prefer - be it io_uring, DPDK, or even just a normal networking interface.
- New method of implementing auxiliary data structures: this is by far the most interesting contribution of the paper. For every new usecase that should be supported, Garnet exposes a very simplified interface to the storage engine via fundamental operations (read, write, scan, delete) and a callback associated with each operation. Thus, every RESP command then becomes a set of callbacks tied to each operation.
- Give an example of a Counter, and how it might be implemented in Garnet RESP
- New storage engine Tsavorite: This is in my opinion the most interesting part of this new database. The storage engine works on the idea that you expose a very simple and limited control surface that consists of four very basic commands and callbacks tied to each command. Thus, the implementation is much simpler and much more easily understood.
- Distributed/Replicated Op Log: Garnet keeps this under the hood and every mutation that happens via Tsavorite is then flushed to the op log, which is the source of truth if you want to cluster/replicate your Garnet cache servers.
The combination of these things allows cache implementers to leverage all the fantastic performance that comes with the relatively simple yet highly optimized interface that Tsavorite offers, while also keeping implementation load relatively simple (and far simpler and more extensible than doing it in Pure C).