Over a million developers have joined DZone.

RavenDB 4.0 Unsung Heroes: Field Compression

DZone's Guide to

RavenDB 4.0 Unsung Heroes: Field Compression

This series of posts is meant to expose some of RavenDB 4.0's hidden features. If we did our job right, you'd never even know that these features exist without this post!

· Database Zone
Free Resource

Read why times series is the fastest growing database category.

I have been talking a lot about major features and making things visible and all sorts of really cool things. What I haven’t been talking about is a lot of the work that has gone into the backend and all the stuff that isn’t sexy and bright. After all, you probably don’t really care how the piping system in your house works — at least until the toilet doesn’t flush.

A lot of the things that we did with RavenDB 4.0 involved at all the pain points that we have run into and trying to resolve them. This series of posts is meant to expose some of these hidden features. If we did our job right, you will never even know that these features exist — they are that good.

In RavenDB 3.x, we had a feature called Document Compression. This allowed a user to save a significant amount of space by having documents stored in a compressed form on disk. If you had large documents, you could typically see significant space savings by enabling this feature. With RavenDB 4.0, we removed it completely. The reason is that we need to store documents in a way that allows us to load them and work with them in their raw form without any additional work. This is key for many optimizations that apply to RavenDB 4.0.

However, that doesn’t mean that we gave up on compression entirely. Instead of compressing the whole document, which would require us to decompress any time that we wanted to do something to it, we selectively compress individual fields. Typically, large documents are large because they have either a few very large fields or they have a collection that contains many items. The blittable format used by RavenDB handles this in two ways. First, we don’t need to repeat field names every time; we store this once per document and we can compress large field values on the fly.

Take my blog, for instance. A lot of the data inside it is actually stored in large text fields (blog posts, comments, etc.). That means that when stored in RavenDB 4.0, we can take advantage of the field compression and reduce the amount of space we use. At the same time, because we are only compressing selected fields, it means that we can still work with the document natively. A trivial example would be to pull the recent blog post titles. We can fetch just these values (and since they are pretty small already, they wouldn’t be compressed) directly and not have to touch the large text field that is the actual post contents.

Here is what this looks like in RavenDB 4.0 when I’m looking at the internal storage breakdown for all documents.


Even though I have been writing for over a decade, I don’t have enough posts yet to make a statistically meaningful difference — the total database sizes for both are 128MB.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

database ,ravendb ,field compression

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}