Over the years, Elasticsearch has improved a lot in reducing memory pressure by introducing doc_values, which is a little slower than the in-memory data structure, fielddata, but still offer reasonable speed and performance. However, because of the way nested and parent-child documents are stored and searched, you should keep the pros and cons in mind before modeling your data. The following is a comparison of nested versus parent-child types, which is nicely outlined by Zachary Tong in one of his articles:
|
Nested |
Parent-Child |
|---|---|
|
Stored in the same Lucene block as each other, which helps in a faster read/query performance. Reading a nested doc is faster than the equivalent parent/child. |
Children are stored separately from the parent, but are routed to the same shard. So parent/children performance is slightly less on read/query than nested. |
|
Updating a single field in a nested document (parent or nested children) forces ES to re-index the entire nested document. This can be very expensive for large nested docs. |
If you are not using doc_values (which is by default since version 2.0.0), parent/child mappings have a bit extra memory overhead since ES maintains a "join" list in the memory. |
|
This is best suited for data that does not change frequently. |
Updating a child doc does not affect the parent or any other children, which can potentially save a lot of indexing on large docs. |