Excerpts From the RavenDB Performance Team Report: JSON & Structs in Voron

what seems to be a pretty set in stone rule of thumb is that when building a fool proof system, you will also find a better fool. in this case, the fool was us.

in particular, during profiling of our systems, we realized that we did something heinous, something so bad that it deserve a true face palm.

in essence, we spent all this time to create a really fast key/value store with voron. we spent man years like crazy to get everything working just so… and then came the time to actually move ravendb to use voron. that was… a big task, easily as big as writing voron in the first place. the requirements ravendb makes of its storage engine are anything but trivial. but we got it working. and it worked good . initial performance testing showed that we were  quite close to the performance of esent, within 10% – 15%, which was good enough for us to go ahead with.

get things working, get them working right and only then get them working fast.

so we spent a lot of time making sure that things worked, and worked right.

and then the time came to figure out if we can make things faster. remember, voron is heavily based around the idea of memory mapping and directly accessing values at very little cost. this is important, because we want to use voron for a whole host of stuff. that said, in ravendb we use it to store json documents, so we obviously store the json in it. there are quite a lot of book keeping information that we keep track of.

in particular, let us focus on the indexing stats. we need to keep track of the last indexed etag per index, when it was changed, number of successful indexing attempts, number of failed indexing attempts, etc.

here is how we updated those stats:

as you can imagine, a lot of the time was actually spent just deserializing and deserializing the data back & forth from json. in fact, a lot of time was spend doing just that.

now, indexing status needs to be queried on every single query , so that was a high priority for us to fix. we did this by not storing the data as json, but storing the data in its raw form directly into voron.

voron gives us a memory of size x, and we put all the relevant data into that memory, and pull the data directly from the raw memory. no need for serialization/deserialization step.

there is a minor issue about the use of strings .while using fixed size structure (like the indexing stats) is really easy, we just read/write to that memory. when dealing with variable length data (such as strings), you have harder time at it, but we dealt with that as well by defining a proper way to encode string lengths and read them back.

the results, by the way:

that means that we got close to 4 times faster! that is certainly going to help us down the road.