đĄ Home đ Chapter đ Prev đ Next
âĄÂ ElasticsearchBook.com is crafted by Jozef Sorocin and powered by:
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:
[join
field type](https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html)[nested
field type](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html).I prefer nested
fields above all else for these three reasons:
[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.
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: