elasticsearch join query based es5.1.1

ElasticSerch join query There are two ways to achieve

• nested
• parent and child associated with the query

---

nested

• Storage structure 
  nested manner as other fields, in which the same type stored in the storage array 
  type, the following format:

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 } ] } 

 

order It was nested

• API query 
  directly .properties of the connection object, as to the order to find the status of the user 2 = direct useorder.status

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

parent / child associated manner

• Storage structure 
  parent / child's memory with nested results are not the same, is stored in a different type, the father-son type relationship to associate by 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" } } } } }

 

 

By  _parent specify a parent type to

• Making data point 
  to add a few user data, and the same general 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" }

 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

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 a few orders to specify type_info by parent

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

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

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

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

 

 

• API query

• By sub-type parent query type, return to the parent type of information 
  query order amount is greater than 60 users, through  has_child query that returns user information

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

 

• Check child by a parent type type, sub-type information return 
  query vip user rating of orders 1 through　has_parent query that returns order information

GET index_test/type_order/_search
{
  "query": {
    "has_parent": {
      "parent_type": "type_info",
      "query": { "term": { "vipType": { "value": 1 } } } } } }

 

and parent-child nested distinction and use scenario

• The main difference: 
  because of different, nested and parent-child structure stored in a manner different scenarios 
  nested all entities stored in the same document, parent-child mode, type the child and parent are stored in different type of document. 
  So nested query efficiency is higher than the parent-child, but the next update when nested models, es will delete the entire document and then create, delete and parent-child will be updated in your document to re-create, does not affect other documents. So update on the efficiency of parent-child than nested.

• Usage scenarios: 
  nested: a small child in a document, and use the case does not change often. 
  For example: an order inside the product, an order can not have thousands of different products, generally not a lot, and once the orders, order products are not updated. 
  parent-child: the use of a large number of documents, and the case will change often happens. 
  For example: the user's browsing history, browsing history will be great, and will be updated frequently