Map a book in elasticsearch with many levels, nested vs parent-child relationship

Question

When creating the mappings for an index that can search through multiple books, is it preferable to use nested mappings like below, or using documents with a parent-child relati

Answer 1

If you use the nested type, everything will be contained in the same _source document, which for big books can be quite a mouthful.

Whereas if you use parent/child docs for each chapters and/or sections, you might end up with smaller chunks which are more chewable...

As always, it heavily depends on the queries you will want to make, so you should first think about all the use cases you will want to support and then you'll be better armed to figure out which approach is best.

There's another approach which uses neither nested nor parent/child, and which simply involves denormalization. Concretely, you pick the smallest "entity" you want to consider, e.g. a section, and then simply create standalone documents for each section. In those section documents, you'd have fields for the book title, author, chapter title, section title, etc.

You can try each approach in their own index and see how it goes for your use cases.

Answer 2

nested is basically a way of stuffing everything into the same document. That can be useful for searching, but it makes certain things considerably harder.

Like - for example - if you're trying to find a particular chapter section - your query will return the correct document - the whole book. I would imagine that's probably not what you're looking for, and thus a parent/child relationship would be the appropriate way to go.

Or just don't bother, and treat book/chapter/section as separate types within an index which query and 'join' on demand.