🏡 Home 📖 Chapter 👈 Prev 👉 Next

⚡  ElasticsearchBook.com is crafted by Jozef Sorocin and powered by:

To Nest or Not to Nest?

If you're coming from an RDB background, you may find it challenging to flatten your document structure to conform with the NoSQL principles that Elasticsearch enforces.

In order to decide which flattening strategy to choose, I'd recommend to first read this blog post that deals with managing document relations.

From my point of view, there are essentially two options to consolidate related documents:

I prefer nested fields above all else for these three reasons:

  1. One document = one single source of truth.
  2. The possibility of a multi-level nested-ness simulating an RDB hierarchy.
  3. The powerful [reverse_nested aggregation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-reverse-nested-aggregation.html) which allows for joining back to a parent document higher up in the nested structure. A real-world example can be found here on SO.

<aside> ⚠️ Nested fields are not suitable for use cases where any of the nested attributes change frequently and need to be updated. Frequent updates can cause performance bottlenecks at scale.

</aside>

Having said that, let's explore a typical DevOps scenario and take full advantage of what nested fields have to offer.

Use Case: Calculating the Median Duration of a Project Build

Let's say we're tracking build pipelines. A build pipeline has 1…n steps, any of which can take any number of milliseconds to run: