Document relationships

Jetzt loslegen. Gratis!
oder registrieren mit Ihrer E-Mail-Adresse
Rocket clouds
Document relationships von 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

1.4.2.1. Untitled

1.5. search in objects

1.5.1. specifying that field's full path

1.5.1.1. Untitled

1.5.1.2. Untitled

1.5.2. aggregations

1.5.2.1. Untitled

1.5.3. objects work best for one-to-one relationships

1.5.3.1. Untitled

1.5.3.2. works well if search in one field

1.5.3.3. if search in multiple fields

1.5.4. pros / cons

1.5.4.1. 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

2.2.3.1. e.g. a group that has both Lee and Radu

2.2.3.2. query that works for object types

2.2.3.2.1. Untitled

2.2.3.3. above query will not work for nested docs

2.2.3.3.1. 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

2.3.2.1. Untitled

2.3.2.2. queries calculate score; thus they are able to return results sorted by relevance

2.3.2.3. filters do not calculate score, making them faster and easier to cache

2.3.3. search in multiple levels of nesting

2.3.3.1. Untitled

2.3.4. aggregations

2.3.4.1. avg

2.3.4.2. total

2.3.4.3. max

2.3.4.4. none

2.3.5. which of the nested documents matched a specific nested query

2.3.5.1. inner hits

2.3.5.1.1. query

2.3.5.1.2. result

2.3.5.2. nested sorting

2.3.5.2.1. Untitled

2.3.5.3. nested

2.3.5.3.1. nested agar doing necessary joins for other agars to work on the indicated path

2.3.5.3.2. Untitled

2.3.5.3.3. Untitled

2.3.5.4. reverse nested aggregations

2.3.5.4.1. 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

3.2.2.1. Untitled

3.2.2.2. vs. nested type

3.2.2.2.1. 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

3.6.2.1. need to specify the _parent value

3.6.2.2. index

3.6.2.3. retrieve

3.6.2.4. update

3.6.2.5. delete

3.7. search in parent/child documents

3.7.1. has_child queries/filters

3.7.1.1. Untitled

3.7.1.1.1. phase1

3.7.1.1.2. phase2

3.7.1.2. getting the child documents in the results

3.7.1.2.1. by default, only the parent documents are returned by the has_child query

3.7.1.2.2. add inner_hits

3.7.2. has_parent queries/filters

3.7.2.1. Untitled

3.7.2.2. only returns on side of the relationship

3.7.2.2.1. the child documents

3.7.3. pros / cons

3.7.3.1. Untitled

4. denormalizing

4.1. def: hierarchical relationship

4.1.1. Untitled

4.1.2. Untitled

4.2. pros/cons

4.2.1. pros

4.2.1.1. Untitled

4.2.2. cons

4.2.2.1. Untitled

4.3. use cases

4.3.1. one to many relations

4.3.1.1. parent-child relations

4.3.1.1.1. child documents are indexed with the same routing value as their parents

4.3.1.1.2. Untitled

4.3.1.2. nested relations

4.3.2. many-to-many relations

4.3.2.1. Untitled

4.3.2.2. Untitled

4.3.2.3. which side will be denormalized

4.3.2.3.1. index documents multiple times, once for each of its parents

4.3.2.3.2. when you update, have to update all instances of that document

4.3.2.3.3. when you delete, have to delete all instances

4.3.2.3.4. 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

4.4.1.1. Untitled

4.4.2. update

4.4.2.1. Untitled

4.4.3. delete

4.4.3.1. Untitled

4.5. query data

4.5.1. Untitled

5. application-side joins

5.1. architecture

5.1.1. Untitled