Document relationships

Get Started. It's Free
or sign up with your email address
Document relationships by Mind Map: Document relationships

1. object type

1.1. a JSON object / an array of JSON objects

1.1.1. Untitled

1.2. internal representation

1.2.1. Untitled

1.3. inner objects boundaries are not accounted for when storing

1.3.1. Untitled

1.4. Mapping and indexing objects

1.4.1. Untitled

1.4.2. the mapping for a single inner object will stay the same if multiple such objects in an array Untitled

1.5. search in objects

1.5.1. specifying that field's full path Untitled Untitled

1.5.2. aggregations Untitled

1.5.3. objects work best for one-to-one relationships Untitled works well if search in one field if search in multiple fields

1.5.4. pros / cons Untitled

2. nested documents

2.1. nested type makes elastic search index objects as separate lucent documents

2.1.1. Untitled

2.1.2. Untitled

2.2. mapping and indexing

2.2.1. Untitled

2.2.2. Untitled

2.2.3. cross object matches e.g. a group that has both Lee and Radu query that works for object types Untitled above query will not work for nested docs mapping options

2.3. searches and aggregations on nested docs

2.3.1. specify that the objects you're looking at are nested

2.3.2. nested query / filter Untitled queries calculate score; thus they are able to return results sorted by relevance filters do not calculate score, making them faster and easier to cache

2.3.3. search in multiple levels of nesting Untitled

2.3.4. aggregations avg total max none

2.3.5. which of the nested documents matched a specific nested query inner hits query result nested sorting Untitled nested nested agar doing necessary joins for other agars to work on the indicated path Untitled Untitled reverse nested aggregations Untitled

2.4. pros/cons

2.4.1. Untitled

3. parent-child relationships between documents

3.1. def

3.1.1. _parent field of each child document is pointing to _id field of its parent

3.1.2. Untitled

3.2. pros

3.2.1. indexing/updating and deleting documents

3.2.2. they can be managed separately Untitled vs. nested type will need to reindex the group documents with new events and all existing events

3.3. use different elastic search documents for different types of data

3.4. query each child, return a parent if there is a match

3.4.1. Untitled

3.5. specify parent's ID in _parent field

3.6. indexing, updating and deleting child documents

3.6.1. define _parent field in the mapping

3.6.2. index/retrieve/update/delete need to specify the _parent value index retrieve update delete

3.7. search in parent/child documents

3.7.1. has_child queries/filters Untitled phase1 phase2 getting the child documents in the results by default, only the parent documents are returned by the has_child query add inner_hits

3.7.2. has_parent queries/filters Untitled only returns on side of the relationship the child documents

3.7.3. pros / cons Untitled

4. denormalizing

4.1. def: hierarchical relationship

4.1.1. Untitled

4.1.2. Untitled

4.2. pros/cons

4.2.1. pros Untitled

4.2.2. cons Untitled

4.3. use cases

4.3.1. one to many relations parent-child relations child documents are indexed with the same routing value as their parents Untitled nested relations

4.3.2. many-to-many relations Untitled Untitled which side will be denormalized index documents multiple times, once for each of its parents when you update, have to update all instances of that document when you delete, have to delete all instances when you query for children separately, you'll get more hits with the same content, so need to remove duplicates on the application side

4.4. index/update/delete data

4.4.1. index Untitled

4.4.2. update Untitled

4.4.3. delete Untitled

4.5. query data

4.5.1. Untitled

5. application-side joins

5.1. architecture

5.1.1. Untitled