1. Nested type: Nested
nested is a kind of object type, which is an index operation for complex type object arrays in Elasticsearch. Elasticsearch has no concept of internal objects. Therefore, when ES stores complex types, it will flatten the complex hierarchical results of objects into a list of key-value pairs.
for example:
json PUT my-index-000001/_doc/1
{
"group": "fans",
"user": [
{
"first": "John",
"last": "Smith"
},
{
"first": "Alice",
"last": "White"
}
]
}
After the above document is created, each json object in the user array will be stored in the following form
{
"group": "fans",
"user.first": [
"alice",
"john"
],
"user.last": [
"smith",
"white"
]
}
The user.first and user.last fields are flattened into multi-valued fields, and the association between first and last is lost.
Use nested to create mappings for complex types:
json PUT <index_name>
{
"mappings": {
"properties": {
"<nested_field_name>": {
"type": "nested"
}
}
}
}
Inquire:
json GET <index_name>/_search
{
"query": {
"nested": {
"path": "<nested_field_name>",
"query": {
...
}
}
}
}
Optin:
path: query depth of nested objects
score_mode: scoring calculation mode
avg (default): use the average relevance score of all matching sub-objects.
max: Use the highest relevance score among all matching subobjects.
min: Use the lowest relevance score among all matching subobjects.
none: Do not use relevance scores for matched sub-objects. This query assigns a score of 0 to the parent document.
sum: Adds the relevance scores of all matching sub-objects.
2. Parent-child relationship: The Join
data type is a special field that creates a parent/child relationship within documents in the same index. The relations section defines a set of possible relations in the document, each relation being a parent name and a child name. A parent/child relationship can be defined as follows
json PUT <index_name>
{
"mappings": {
"properties": {
"<join_field_name>": {
"type": "join",
"relations": {
"<parent_name>": "<child_name>"
}
}
}
}
}
scenes to be used
The join type cannot be used like a table link in a relational database. Whether it is a has_child or has_parent query, it will have a serious negative impact on the query performance of the index. And will trigger global ordinals
The only suitable use case for join is when the index data contains a one-to-many relationship, and the number of one entity far exceeds the other. Example: A teacher has 10,000 students
Notice
When indexing parent-child relationship data, the routing parameter must be passed in, that is, to specify which shard to store the data in, because the parent document and the child document must be on the same shard, therefore, when obtaining, deleting or updating the child document, you need to provide the same routing value.
Only one field mapping of join type is allowed per index
An element can have multiple children but only one parent
New relationships can be added to existing join fields
and children can be added to existing elements, but only if the element is already a parent element