Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to deal with elasticsearch father and son documents". In daily operation, I believe many people have doubts about how to deal with elasticsearch father and son documents. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts of "how to deal with elasticsearch father and son documents". Next, please follow the editor to study!

I. background

In the course of our work, there are times when we need to use the relational mapping of parent-child documents. * for example: * * there are multiple answers to a question, multiple reviews in a book, and so on. Here we can use es's jion data type or nested to implement it. Here we use join to establish a parent-child document relationship in es.

II. Demand

We need to create a plan, under which there are activities (activity) and books (book), and under books there are reviews (comments).

That is, the hierarchical structure is:

Plan /\ /\ activity book | | comments III. Pre-knowledge

There can be only one field of type join per mapping.

The parent document and child document must be on the same shard. That is, adding, deleting, modifying and checking a child document must use the same routing key as the parent document.

Each element can have only one parent, but there can be multiple children.

You can add a new association to an existing join field.

You can add a child element to an element that is already a parent.

Join data types should not be used in elasticsearch like relational databases. And both has_child and has_parent consume performance.

Using join makes sense only when the data of the child is much larger than that of the parent. For example: under a blog, there are multiple comments.

Step 1: create mappingPUT / plan_index {"settings": {"number_of_shards": 3, "number_of_replicas": 1}, "mappings": {"properties": {"plan_id": {"type": "keyword"}, "plan_name": {"type": "text" "fields": {"keyword": {"type": "keyword", "ignore_above": 256}, "act_id": {"type": "keyword"}, "act_name": {"type": "text" "fields": {"keyword": {"type": "keyword", "ignore_above": 256}, "comment_id": {"type": "keyword"}, "comment_name": {"type": "text" "fields": {"keyword": {"type": "keyword", "ignore_above": 256}, "creator": {"type": "keyword"}, "create_time": {"type": "date" "format": "yyyy-MM-dd | | yyyy-MM-dd HH:mm:ss"}, "plan_join": {"type": "join", "relations": {"plan": ["activity", "book"], "book": "comments"}

Pay attention to ⚠️

2. Add parent document data

What is added here is (plan) data.

PUT / plan_index/_doc/plan-001 {"plan_id": "plan-001", "plan_name": "April Plan", "creator": "huan", "create_time": "2021-04-07 16:27:30", "plan_join": {"name": "plan"} PUT / plan_index/_doc/plan-002 {"plan_id": "plan-002" "plan_name": "May Plan", "creator": "huan", "create_time": "2021-05-07 16:27:30", "plan_join": "plan"}

Note ⚠️:

1. If you are creating a parent document, you need to use plan_join to specify the name of the parent document's relationship (in this case, plan).

2. When plan_join is the mapping that creates the index, specify the name of the field of join.

3. When you specify a parent document, both of these two ways of writing plan_join can be used.

3. Add subdocuments PUT / plan_index/_doc/act-001?routing=plan-001 {"act_id": "act-001", "act_name": "first activity in April", "creator": "huan.fu", "plan_join": {"name": "activity", "parent": "plan-001"} PUT / plan_index/_doc/book-001?routing=plan-001 {"book_id": "book-001" "book_name": "first Book read in April", "creator": "huan.fu", "plan_join": {"name": "book", "parent": "plan-001"} PUT / plan_index/_doc/book-002?routing=plan-001 {"book_id": "book-002", "book_name": "programming Zhuji", "creator": "huan.fu" "plan_join": {"name": "book", "parent": "plan-001"} PUT / plan_index/_doc/book-003?routing=plan-002 {"book_id": "book-003", "book_name": "java programming ideas", "creator": "huan.fu", "plan_join": {"name": "book" "parent": "plan-002"} # theoretically, the parent document of comment is book But it is also possible for routing to use plan here. PUT / plan_index/_doc/comment-001?routing=plan-001 {"comment_id": "comment-001", "comment_name": "this book is OK", "creator": "huan.fu", "plan_join": {"name": "comments", "parent": "book-001"} PUT / plan_index/_doc/comment-002?routing=plan-001 {"comment_id": "comment-002", "comment_name": "worth reading" Great. " , "creator": "huan.fu", "plan_join": {"name": "comments", "parent": "book-001"}}

Note ⚠️:

1. Child documents (descendant documents, etc.) need to use the same routing key as the parent document.

2. You need to specify the id of the parent document.

3. You need to specify the name of join.

4. Query the document 1. Query the child documents below it according to the parent document id

* * requirements: * * return all child documents of type book under plan-001 whose parent document id is.

GET / plan_index/_search {"query": {"parent_id": {"type": "book", "id": "plan-001"}} 2. Has_child returns the parent document that meets the criteria.

* * requirements: * * returns the parent document whose creator is huan.fu and has at least 2 child documents.

GET / plan_index/_search {"query": {"has_child": {"type": "book", "min_children": 2, "query": {"match": {"creator": "huan.fu"}

3. Has_parent returns child documents that satisfy the parent document

* * requirements: * * the creator of the returned parent document (book) is all child documents of huan.fu.

GET / plan_index/_search {"query": {"has_parent": {"parent_type": "book", "query": {"match": {"creator": "huan.fu"}

Fifth, Nested Object and join compared to Nested Objectjoin (Parent/Child) 1, documents are stored together, reading performance is high 1, parent-child documents are stored separately, and do not affect each other. However, in order to maintain the join relationship, it needs to take up extra content, and the read performance is slightly poor. 2. When you update a parent or child document, you need to update the entire document. 2. Parent and child documents can be updated separately. 3. It is suitable for frequent queries and occasional updates of subdocuments. 3. It is suitable for frequent updates, and the number of child documents far exceeds the number of parent documents. At this point, the study on "how to deal with elasticsearch parent-son documents" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.