+972 52-548-6969
Writing a time series database with Voron
Following up on this post, I wondered what it would be like if I were to implement this with Voron. Given that Voron was explicitly designed to be a low level storage engine, suitable for varying needs, it is an interesting experiment.
Let us define upfront what we want to do:
We use BlittableJsonReaderObject as the key in the add because initializing a dictionary per add call would be ridiculously expensive. The blittable instance is much cheaper, and its associated memory can be cleaned when it is done much more easily.
Here is how we handle the append:
There isn’t much here, and that is quite intentional. What you are seeing here is transaction merging. Instead of having to compete on the same lock, we just place the value to be written on the queue, and wait for it to complete. The other side of that is the transaction merging itself:
Please note that I didn’t really focus on performance here, just to make sure that this is clear. Basically, we use the hash of the key as the time series id, and then we break the key into name/value pieces, and record the time series ids of all the series with that particular name/value. That allows us to get the list of all the series that match a particular name/value easily, and from there we can do more complex filtering.
We are using a FixedSizeTree for quite a lot, this is basically a tree whose key is always a long, and whose value is predefined (in this case, a double), and we just store that based on the time series id.
Querying this will require us to first find all the series that match the query, then find the relevant values in the time range for the specified series, and that is all 
.
Comments
I read some of the prometheus product docs, it doesn't seem to be ACID, which helps with performance, but I don't see how you can compare it to ravendb. you can configure the checkpointing to control how much data you are willing to lose in a crash.
Peter, he's not comparing it to RavenDb, but to Voron. As Ayende says in the article Voron is a "low level storage engine".
@eirik, I understood that, and actually debated whether to use "ravendb" or "voron". I decided that "prometheus" is the whole product, they dont name their storage engine separately, so I did the same. In addition, I don't know how much of the performance is affected by the leveldb indexing, and if their benchmarks include the indexing or just the storing.
Comment preview