ElasticSearch join connection query

ElasticSearch join connection query

Special Note: All content of the article is based on ElasticSerch 5.5.3 version

ElasticSerch's connection query can be implemented in two ways

• nested
• parent and child association query

---

nested

• The storage structure
  nested is stored in the same type as other fields, stored in
  the type as an array, and the format is as follows:

PUT index_test/type_info/1000
{
    
    
  "userId": 1000,
  "mobile": "13301020202",
  "nick": "梅西",
  "vipType": 1,
  "vipPoints": 1200,
  "regTime": "2018-06-18 12:00:31",
  "order": [
    {
    
    
      "status": 1,
      "payMethod": 2,
      "amount": 100,
      "productCount": 3
    },
    {
    
    
      "status": 2,
      "payMethod": 2,
      "amount": 230,
      "productCount": 1
    }
  ]
}

orderis nested

• API query method
  Directly use .the properties of the connection object, if you want to find the user whose status is 2 in the order, use it directlyorder.status

GET index_test/type_info/_search
{
    
    
  "query": {
    
    
    "term": {
    
    
      "order.status": 2
    }
  }
}

The way parent / child is associated

• The storage result of the storage structure
  parent / child is different from nested, it is stored in a different type, and the parent-child type relationship is associated through the parent

PUT index_test
{
    
    
 "mappings": {
    
    
   "type_info": {
    
    
     "properties": {
    
    
       "userId": {
    
    
         "type": "integer"
       },
       "mobile": {
    
    
         "type": "keyword"
       },
       "nick": {
    
    
         "type": "keyword"
       },
       "vipType": {
    
    
         "type": "integer"
       },
       "vipPoints": {
    
    
         "type": "integer"
       },
       "regTime": {
    
    
         "type": "date",
         "format": "yyyy-MM-dd HH:mm:ss"
       }
     }
   },
   "type_order": {
    
    
     "_parent": {
    
    
       "type": "type_info"
     },
     "properties": {
    
    
       "amount": {
    
    
         "type": "scaled_float",
         "scaling_factor": 100
       },
       "payMethod": {
    
    
         "type": "integer"
       },
       "status": {
    
    
         "type": "integer"
       },
       "productCount": {
    
    
         "type": "integer"
       }
     }
   }
 }
}

_parentSpecify the parent type by

• Create some data
  Add a few pieces of user data, the same as the normal type, there is no difference

PUT index_test/type_info/1000
{
    
    
 "userId": 1000,
 "mobile": "13301020202",
 "nick": "梅西",
 "vipType": 1,
 "vipPoints": 1200,
 "regTime": "2018-06-18 12:00:31"
}

PUT index_test/type_info/1001
{
    
    
 "userId": 1001,
 "mobile": "151232223",
 "nick": "C罗",
 "vipType": 1,
 "vipPoints": 300,
 "regTime": "2018-05-18 12:00:00"
}

PUT index_test/type_info/1002
{
    
    
 "userId": 1002,
 "mobile": "181829282",
 "nick": "内马尔",
 "vipType": 2,
 "vipPoints": 1300,
 "regTime": "2018-09-09 12:00:00"
}

Add several pieces of order data, specify type_info by parent

PUT index_test/type_order/100?parent=1000
{
    
    
"userId": 1000,
"amount": 300,
"payMethod": 2,
"status": 3,
"productCount": 2
}

```javascript

PUT index_test/type_order/101?parent=1000
{
“userId”: 1000,
“amount”: 250,
“payMethod”: 1,
“status”: 2,
“productCount”: 1
}

  ```javascript
PUT index_test/type_order/102?parent=1001
{
"userId": 1001,
"amount": 56,
"payMethod": 1,
"status": 2,
"productCount": 1
}

```javascript

PUT index_test/type_order/103?parent=1002
{
“userId”: 1002,
“amount”: 78,
“payMethod”: 2,
“status”: 1,
“productCount”: 2
}

- API查询方式
- 通过子type查询父type，返回父type信息
查询下单金额大于60的用户，通过 `has_child` 查询，返回用户信息

GET index_test/type_info/_search
{
“query”: {
“has_child”: {
“type”: “type_order”,
“query”: {
“range”: {
“amount”: {
“gte”: 60
}
}
}
}
}
}

 - 通过父type查子type，返回子type信息
查询vip等级为1的用户下的订单，通过　`has_parent` 查询，返回订单信息
```javascript
GET index_test/type_order/_search
{
 "query": {
   "has_parent": {
     "parent_type": "type_info",
     "query": {
       "term": {
         "vipType": {
           "value": 1
         }
       }
     }
   }
 }
}

The difference between nested and parent-child and usage scenarios

• The main difference:
  due to the different storage structures, nested and parent-child methods have different application scenarios.
  In nested, all entities are stored in the same document. In parent-child mode, child types and parent types are stored in different documents.
  Therefore, the query efficiency of nested is higher than that of parent-child, but when updating, in nested mode, es will delete the entire document and recreate it, while parent-child will only delete the document you updated and recreate it, without affecting other documents. Therefore, parent-child is higher than nested in terms of update efficiency.

• Usage scenarios:
  nested: used when there are a small number of sub-documents and they do not change frequently.
  For example: for the products in an order, it is impossible for an order to have thousands of different products, generally not many, and once an order is placed, the ordered product cannot be updated.
  parent-child: Used when there are a large number of documents and they will change frequently.
  For example: the user's browsing history, the browsing history will be very large and will be updated frequently