在Elasticsearch這樣的分布式系統(tǒng)中執(zhí)行類似SQL的join連接是代價是比較大的，然而，Elasticsearch卻給我們提供了基于水平擴展的兩種連接形式 。這句話摘自Elasticsearch官網(wǎng)，從“然而”來看，說明某些場景某些情況下我們還是可以使用的
【資料圖】
一、join總述
1、關系類比
在關系型數(shù)據(jù)庫中，以MySQL為例，尤其B端類系統(tǒng)且數(shù)據(jù)量不是特別大的場景，我們經(jīng)常用到join關鍵字對有關系的兩張或者多張表進行關聯(lián)查詢。但是當數(shù)據(jù)量達到一定量級時，查詢性能就是經(jīng)常困擾的問題。由于es可以做到數(shù)億量級的秒查（具體由分片數(shù)量決定），這時候把數(shù)據(jù)同步到es是我們可以使用解決方案之一。
那么不禁有疑問問了，由于業(yè)務場景的決定，之前必須關聯(lián)查詢的兩張表還能做到進行關聯(lián)嗎？
答案是可以的，es也提供了類似于關系型數(shù)據(jù)庫的關聯(lián)查詢，但是它又與關系型數(shù)據(jù)的關聯(lián)查詢有明顯的區(qū)別與限制。
2、使用場景
如果把關系數(shù)據(jù)庫原有關聯(lián)的兩張表，同步到es后，通常情況下，我們業(yè)務開發(fā)中會有兩種查詢訴求的場景
場景1
訴求：展示子表維度的明細數(shù)據(jù)（包含父表和子表中字段的條件）
方案：對于此種查詢訴求，我們可以把原來關聯(lián)的父子表打成父子表字段混合在一起的大寬表，既能滿足查詢條件，又有查詢性能的保障，也是常用存儲方案之一
場景2
訴求：展示父表維度的明細數(shù)據(jù)（包含父表和子表中字段的條件）
方案：然而，對于此種查詢訴求，需要通過子表的條件來查詢出父表的明細結(jié)果，場景1的寬表存儲方案是子表明細數(shù)據(jù)，而最終我們要的是父表明細數(shù)據(jù)，顯然對于場景1的存儲方案是不能滿足的。如果非要使用場景1的存儲方案，我們還要對寬表結(jié)果進行一次groupby或者collapse操作來得到父表結(jié)果。
這個時候我們就可以使用es提供的join功能來完成場景2的訴求查詢，同時它也滿足場景1的訴求查詢
3、使用限制
由于es屬于分布式文檔型數(shù)據(jù)庫，數(shù)據(jù)自然是存在于多個分片之上的。Join字段自然不能像關系型數(shù)據(jù)庫中的join使用。在es中為了保證良好的查詢性能，最佳的實踐是將數(shù)據(jù)模型設置為非規(guī)范化文檔，通過字段冗余構(gòu)造寬表，即存儲在一個索引中。需要滿足條件如下：
（1）父子文檔(數(shù)據(jù))必須存儲在同一index中
（2）父子文檔(數(shù)據(jù))必須存儲在同一個分片中，通過關聯(lián)父文檔ID關聯(lián)
（3）一個index中只能包含一個join字段，但是可以有多個關系
（4）同一個index中，一個父關系可以對應多個子關系，一個子關系只對應一個父關系
4、性能問題
當然執(zhí)行了join查詢固然性能會受到一定程度的影響。對于帶has_child/has_parent而言，其查詢性能會隨著指向唯一父文檔的匹配子文檔的數(shù)量增加而降低。本文開篇第一句摘自es官網(wǎng)描述，從ES官方的描述來看join關聯(lián)查詢對性能的損耗是比較大的。
不過，在筆者使用的過程中，在5個分片的前提下，且父表十萬量級，子表數(shù)據(jù)量在千萬量級的情況下，關聯(lián)查詢的耗時還是在100ms內(nèi)完成的，對于B端許多場景還是可以接受的。
若有類似場景，建議我們在使用前，根據(jù)分片的多少和預估未來數(shù)據(jù)量的大小提前做好性能測試，防止以后數(shù)量達到一定程度時，性能有明顯下降，那個時候再改存儲方案得不償失。
二、Mapping
1、舉例說明
這里以優(yōu)惠券活動與優(yōu)惠券明細為例，在一個優(yōu)惠券活動中可以發(fā)放幾千萬的優(yōu)惠券，所以券活動與券明細是一對多的關系。
券活動表字段
字段
說明
activity_id
活動ID
activity_name
活動名稱
券明細表字段
字段
說明
coupon_id
券ID
coupon_amount
券面額
activity_id
外鍵-活動ID
2、mapping釋義
join類型的字段主要用來在同一個索引中構(gòu)建父子關聯(lián)關系。通過relations定義一組父子關系，每個關系都包含一個父級關系名稱和一個或多個子級關系名稱
activity_coupon_field是一個關聯(lián)字段，內(nèi)部定義了一組join關系，該字段為自命名
type指定關聯(lián)關系是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"
}
}
}
}
三、插入數(shù)據(jù)
1、插入父文檔
在put父文檔數(shù)據(jù)的時候，我們通常按照某種規(guī)則指定文檔ID，方便子文檔數(shù)據(jù)變更時易于得到父文檔ID。比如這里我們用activity_id的值：activity_100來作為父id
PUT /coupon/_doc/activity_100
{
"activity_id": 100,
"activity_name": "年貨節(jié)5元促銷優(yōu)惠券",
"activity_coupon_field": {
"name": "activity"
}
}
2、插入子文檔
上邊已經(jīng)指定了父文檔ID，而子表中已經(jīng)包含有activity_id，所以很容易得到父文檔ID
put子文檔數(shù)據(jù)時候，必須指定父文檔ID，就是父文檔中的_id，這樣父子數(shù)據(jù)才建立了關聯(lián)關系。與此同時還要指定routing字段為父文檔ID，這樣保證了父子數(shù)據(jù)在同一分片上。
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
}
}
四、關聯(lián)查詢
1、has_parent查詢（父查子）
根據(jù)父文檔條件字段查詢符合條件的子文檔數(shù)據(jù)
例如：查詢包含“年貨節(jié)”活動字樣，且已經(jīng)被領取過的券
{
"query": {
"bool": {
"must": [{
"parent_type": "activity",
"has_parent": {
"query": {
"bool": {
"must": [{
"term": {
"status": {
"value": 1
}
}
}, {
"wildcard": {
"activity_name": {
"wildcard": "*年貨節(jié)*"
}
}
}]
}
}
}
}]
}
}
}
2、has_child查詢（子查父）
根據(jù)子文檔條件字段符合條件的父文檔數(shù)據(jù)
例如：查詢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
以上文中如有不正之處歡迎留言指正
作者：京東零售 李振乾
內(nèi)容來源：京東云開發(fā)者社區(qū)
關鍵詞：
責任編輯：Rex_30
