在Elasticsearch這樣的分散式系統中執行類似SQL的join連線是代價是比較大的，然而，Elasticsearch卻給我們提供了基於水平擴充套件的兩種連線形式 。這句話摘自Elasticsearch官網，從「然而」來看，說明某些場景某些情況下我們還是可以使用的
在關係型資料庫中，以MySQL為例，尤其B端類系統且資料量不是特別大的場景，我們經常用到join關鍵字對有關係的兩張或者多張表進行關聯查詢。但是當資料量達到一定量級時，查詢效能就是經常困擾的問題。由於es可以做到數億量級的秒查（具體由分片數量決定），這時候把資料同步到es是我們可以使用解決方案之一。
那麼不禁有疑問問了，由於業務場景的決定，之前必須關聯查詢的兩張表還能做到進行關聯嗎？
答案是可以的，es也提供了類似於關係型資料庫的關聯查詢，但是它又與關係型資料的關聯查詢有明顯的區別與限制。
如果把關聯式資料庫原有關聯的兩張表，同步到es後，通常情況下，我們業務開發中會有兩種查詢訴求的場景
場景1
訴求：展示子表維度的明細資料（包含父表和子表中欄位的條件）
方案：對於此種查詢訴求，我們可以把原來關聯的父子表打成父子表欄位混合在一起的大寬表，既能滿足查詢條件，又有查詢效能的保障，也是常用儲存方案之一
場景2
訴求：展示父表維度的明細資料（包含父表和子表中欄位的條件）
方案：然而，對於此種查詢訴求，需要通過子表的條件來查詢出父表的明細結果，場景1的寬表儲存方案是子表明細資料，而最終我們要的是父表明細資料，顯然對於場景1的儲存方案是不能滿足的。如果非要使用場景1的儲存方案，我們還要對寬表結果進行一次groupby或者collapse操作來得到父表結果。
這個時候我們就可以使用es提供的join功能來完成場景2的訴求查詢，同時它也滿足場景1的訴求查詢
由於es屬於分散式檔案型資料庫，資料自然是存在於多個分片之上的。Join欄位自然不能像關係型資料庫中的join使用。在es中為了保證良好的查詢效能，最佳的實踐是將資料模型設定為非規範化檔案，通過欄位冗餘構造寬表，即儲存在一個索引中。需要滿足條件如下：
（1）父子檔案(資料)必須儲存在同一index中
（2）父子檔案(資料)必須儲存在同一個分片中，通過關聯父檔案ID關聯
（3）一個index中只能包含一個join欄位，但是可以有多個關係
（4）同一個index中，一個父關係可以對應多個子關係，一個子關係只對應一個父關係
當然執行了join查詢固然效能會受到一定程度的影響。對於帶has_child/has_parent而言，其查詢效能會隨著指向唯一父檔案的匹配子檔案的數量增加而降低。本文開篇第一句摘自es官網描述，從ES官方的描述來看join關聯查詢對效能的損耗是比較大的。
不過，在筆者使用的過程中，在5個分片的前提下，且父表十萬量級，子表資料量在千萬量級的情況下，關聯查詢的耗時還是在100ms內完成的，對於B端許多場景還是可以接受的。
若有類似場景，建議我們在使用前，根據分片的多少和預估未來資料量的大小提前做好效能測試，防止以後數量達到一定程度時，效能有明顯下降，那個時候再改儲存方案得不償失。
這裡以優惠券活動與優惠券明細為例，在一個優惠券活動中可以發放幾千萬的優惠券，所以券活動與券明細是一對多的關係。
券活動表欄位
| 欄位 | 說明 |
|---|---|
| activity_id | 活動ID |
| activity_name | 活動名稱 |
券明細表欄位
| 欄位 | 說明 |
|---|---|
| coupon_id | 券ID |
| coupon_amount | 券面額 |
| activity_id | 外來鍵-活動ID |
join型別的欄位主要用來在同一個索引中構建父子關聯關係。通過relations定義一組父子關係，每個關係都包含一個父級關係名稱和一個或多個子級關係名稱
activity_coupon_field是一個關聯欄位，內部定義了一組join關係，該欄位為自命名
type指定關聯關係是join，固定寫法
relations定義父子關係，activity父類別型名稱，coupon子型別名稱，名稱均為自命名
{
"mappings": {
"properties": {
"activity_coupon_field": {
"type": "join",
"relations": {
"activity": "coupon"
}
},
"activity_id": {
"type": "keyword"
},
"activity_name": {
"type": "keyword"
},
"coupon_id": {
"type": "long"
},
"coupon_amount": {
"type": "long"
}
}
}
}
在put父檔案資料的時候，我們通常按照某種規則指定檔案ID，方便子檔案資料變更時易於得到父檔案ID。比如這裡我們用activity_id的值：activity_100來作為父id
PUT /coupon/_doc/activity_100
{
"activity_id": 100,
"activity_name": "年貨節5元促銷優惠券",
"activity_coupon_field": {
"name": "activity"
}
}
上邊已經指定了父檔案ID，而子表中已經包含有activity_id，所以很容易得到父檔案ID
put子檔案資料時候，必須指定父檔案ID，就是父檔案中的_id，這樣父子資料才建立了關聯關係。與此同時還要指定routing欄位為父檔案ID，這樣保證了父子資料在同一分片上。
PUT /coupon/_doc/coupon_12345678?routing=activity_id_100
{
"coupon_id": 12345678,
"coupon_amount": "5",
"activity_id": 100,
"activity_coupon_field": {
"name": "coupon",
"parent": "activity_id_100" //父ID
}
}
根據父檔案條件欄位查詢符合條件的子檔案資料
例如：查詢包含「年貨節」活動字樣，且已經被領取過的券
{
"query": {
"bool": {
"must": [{
"parent_type": "activity",
"has_parent": {
"query": {
"bool": {
"must": [{
"term": {
"status": {
"value": 1
}
}
}, {
"wildcard": {
"activity_name": {
"wildcard": "*年貨節*"
}
}
}]
}
}
}
}]
}
}
}
根據子檔案條件欄位符合條件的父檔案資料
例如：查詢coupon_id=12345678在那個存在於哪個券活動中
{
"query": {
"bool": {
"must": [{
"has_child": {
"type": "coupon",
"query": {
"bool": {
"must": [{
"term": {
"coupon_id": {
"value": 12345678
}
}
}]
}
}
}
}]
}
}
}
參考：Joining queries | Elasticsearch Guide [7.9] | Elastic
以上文中如有不正之處歡迎留言指正
作者：京東零售 李振乾
內容來源：京東雲開發者社群