首頁 >深度 >

Elasticsearch之join關(guān)聯(lián)查詢及使用場(chǎng)景

在Elasticsearch這樣的分布式系統(tǒng)中執(zhí)行類似SQL的join連接是代價(jià)是比較大的,然而,Elasticsearch卻給我們提供了基于水平擴(kuò)展的兩種連接形式 。這句話摘自Elasticsearch官網(wǎng),從“然而”來看,說明某些場(chǎng)景某些情況下我們還是可以使用的


【資料圖】

一、join總述

1、關(guān)系類比

在關(guān)系型數(shù)據(jù)庫中,以MySQL為例,尤其B端類系統(tǒng)且數(shù)據(jù)量不是特別大的場(chǎng)景,我們經(jīng)常用到j(luò)oin關(guān)鍵字對(duì)有關(guān)系的兩張或者多張表進(jìn)行關(guān)聯(lián)查詢。但是當(dāng)數(shù)據(jù)量達(dá)到一定量級(jí)時(shí),查詢性能就是經(jīng)常困擾的問題。由于es可以做到數(shù)億量級(jí)的秒查(具體由分片數(shù)量決定),這時(shí)候把數(shù)據(jù)同步到es是我們可以使用解決方案之一。

那么不禁有疑問問了,由于業(yè)務(wù)場(chǎng)景的決定,之前必須關(guān)聯(lián)查詢的兩張表還能做到進(jìn)行關(guān)聯(lián)嗎?

答案是可以的,es也提供了類似于關(guān)系型數(shù)據(jù)庫的關(guān)聯(lián)查詢,但是它又與關(guān)系型數(shù)據(jù)的關(guān)聯(lián)查詢有明顯的區(qū)別與限制。

2、使用場(chǎng)景

如果把關(guān)系數(shù)據(jù)庫原有關(guān)聯(lián)的兩張表,同步到es后,通常情況下,我們業(yè)務(wù)開發(fā)中會(huì)有兩種查詢?cè)V求的場(chǎng)景

場(chǎng)景1

訴求:展示子表維度的明細(xì)數(shù)據(jù)(包含父表和子表中字段的條件)

方案:對(duì)于此種查詢?cè)V求,我們可以把原來關(guān)聯(lián)的父子表打成父子表字段混合在一起的大寬表,既能滿足查詢條件,又有查詢性能的保障,也是常用存儲(chǔ)方案之一

場(chǎng)景2

訴求:展示父表維度的明細(xì)數(shù)據(jù)(包含父表和子表中字段的條件)

方案:然而,對(duì)于此種查詢?cè)V求,需要通過子表的條件來查詢出父表的明細(xì)結(jié)果,場(chǎng)景1的寬表存儲(chǔ)方案是子表明細(xì)數(shù)據(jù),而最終我們要的是父表明細(xì)數(shù)據(jù),顯然對(duì)于場(chǎng)景1的存儲(chǔ)方案是不能滿足的。如果非要使用場(chǎng)景1的存儲(chǔ)方案,我們還要對(duì)寬表結(jié)果進(jìn)行一次groupby或者collapse操作來得到父表結(jié)果。

這個(gè)時(shí)候我們就可以使用es提供的join功能來完成場(chǎng)景2的訴求查詢,同時(shí)它也滿足場(chǎng)景1的訴求查詢

3、使用限制

由于es屬于分布式文檔型數(shù)據(jù)庫,數(shù)據(jù)自然是存在于多個(gè)分片之上的。Join字段自然不能像關(guān)系型數(shù)據(jù)庫中的join使用。在es中為了保證良好的查詢性能,最佳的實(shí)踐是將數(shù)據(jù)模型設(shè)置為非規(guī)范化文檔,通過字段冗余構(gòu)造寬表,即存儲(chǔ)在一個(gè)索引中。需要滿足條件如下:

(1)父子文檔(數(shù)據(jù))必須存儲(chǔ)在同一index中

(2)父子文檔(數(shù)據(jù))必須存儲(chǔ)在同一個(gè)分片中,通過關(guān)聯(lián)父文檔ID關(guān)聯(lián)

(3)一個(gè)index中只能包含一個(gè)join字段,但是可以有多個(gè)關(guān)系

(4)同一個(gè)index中,一個(gè)父關(guān)系可以對(duì)應(yīng)多個(gè)子關(guān)系,一個(gè)子關(guān)系只對(duì)應(yīng)一個(gè)父關(guān)系

4、性能問題

當(dāng)然執(zhí)行了join查詢固然性能會(huì)受到一定程度的影響。對(duì)于帶has_child/has_parent而言,其查詢性能會(huì)隨著指向唯一父文檔的匹配子文檔的數(shù)量增加而降低。本文開篇第一句摘自es官網(wǎng)描述,從ES官方的描述來看join關(guān)聯(lián)查詢對(duì)性能的損耗是比較大的。

不過,在筆者使用的過程中,在5個(gè)分片的前提下,且父表十萬量級(jí),子表數(shù)據(jù)量在千萬量級(jí)的情況下,關(guān)聯(lián)查詢的耗時(shí)還是在100ms內(nèi)完成的,對(duì)于B端許多場(chǎng)景還是可以接受的。

若有類似場(chǎng)景,建議我們?cè)谑褂们?,根?jù)分片的多少和預(yù)估未來數(shù)據(jù)量的大小提前做好性能測(cè)試,防止以后數(shù)量達(dá)到一定程度時(shí),性能有明顯下降,那個(gè)時(shí)候再改存儲(chǔ)方案得不償失。

二、Mapping

1、舉例說明

這里以優(yōu)惠券活動(dòng)與優(yōu)惠券明細(xì)為例,在一個(gè)優(yōu)惠券活動(dòng)中可以發(fā)放幾千萬的優(yōu)惠券,所以券活動(dòng)與券明細(xì)是一對(duì)多的關(guān)系。

券活動(dòng)表字段

字段

說明

activity_id

活動(dòng)ID

activity_name

活動(dòng)名稱

券明細(xì)表字段

字段

說明

coupon_id

券ID

coupon_amount

券面額

activity_id

外鍵-活動(dòng)ID

2、mapping釋義

join類型的字段主要用來在同一個(gè)索引中構(gòu)建父子關(guān)聯(lián)關(guān)系。通過relations定義一組父子關(guān)系,每個(gè)關(guān)系都包含一個(gè)父級(jí)關(guān)系名稱和一個(gè)或多個(gè)子級(jí)關(guān)系名稱

activity_coupon_field是一個(gè)關(guān)聯(lián)字段,內(nèi)部定義了一組join關(guān)系,該字段為自命名

type指定關(guān)聯(lián)關(guān)系是join,固定寫法

relations定義父子關(guān)系,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ù)的時(shí)候,我們通常按照某種規(guī)則指定文檔ID,方便子文檔數(shù)據(jù)變更時(shí)易于得到父文檔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ù)時(shí)候,必須指定父文檔ID,就是父文檔中的_id,這樣父子數(shù)據(jù)才建立了關(guān)聯(lián)關(guān)系。與此同時(shí)還要指定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

}

}

四、關(guān)聯(lián)查詢

1、has_parent查詢(父查子)

根據(jù)父文檔條件字段查詢符合條件的子文檔數(shù)據(jù)

例如:查詢包含“年貨節(jié)”活動(dòng)字樣,且已經(jīng)被領(lǐ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在那個(gè)存在于哪個(gè)券活動(dòng)中

{

"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ū)

關(guān)鍵詞:

責(zé)任編輯:Rex_30

推薦閱讀