Apache Ignite1.7有哪些新特性

這篇文章主要講解了“Apache Ignite1.7有哪些新特性”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Apache Ignite1.7有哪些新特性”吧！

Apache Ignite 1.7的新特性-非并置的分布式關(guān)聯(lián)

最近，Apache Ignite發(fā)布了1.7.0版，在眾多的改變中，有一個眾多Apache Ignite用戶和客戶期待已久的殺手級特性-SQL查詢支持非并置的分布式關(guān)聯(lián)。本文會聚焦于這個特性，詳細(xì)描述非并置的分布式關(guān)聯(lián)是如何工作的以及它與傳統(tǒng)的（基于關(guān)系并置）Apache Ignite關(guān)聯(lián)有何不同。

基于關(guān)系并置的關(guān)聯(lián)

以前，Apache Ignite支持跨多個不同表的SQL關(guān)聯(lián)查詢，但是要求一個查詢中關(guān)聯(lián)的緩存數(shù)據(jù)要并置在一起。實(shí)際上在Ignite中，并置通過關(guān)系鍵可以非常方便地啟用，這時，一個業(yè)務(wù)實(shí)體的數(shù)據(jù)會與另一個相關(guān)業(yè)務(wù)實(shí)體的數(shù)據(jù)存儲于同一個節(jié)點(diǎn)。 比如，假設(shè)有兩個業(yè)務(wù)實(shí)體，Organization和Person，并且一個Organization的Id會作為來自該Organization的Person的一個關(guān)系鍵。然后，Ignite會確保將Person的所有數(shù)據(jù)存儲于他們所屬的Organization數(shù)據(jù)所在的節(jié)點(diǎn)上，這個簡單的概念可以執(zhí)行一系列可以想象的兼容于ANSI-99的SQL查詢，包括多個緩存的關(guān)聯(lián)。 基本上，一個使用關(guān)聯(lián)的SQL查詢與一個沒有關(guān)聯(lián)的SQL查詢的執(zhí)行流程是絕對一致的。 我們可以看一下一個很基本的查詢的執(zhí)行流程，它使用Organization和Person業(yè)務(wù)實(shí)體通過如下方式定義：

• Organization(id, address)實(shí)體：這個id會作為Organization的ID，它的值在將Organization注入緩存時會作為緩存鍵，這個用作緩存鍵的鍵在Ignite的SQL引擎層會被視為一個主鍵，這個概念會貫穿本文始終。

• Person(name, salary)實(shí)體：位于Persons緩存，會使用AffinityKey(id, orgId)作為緩存鍵，這里AffinityKey是Ignite中的一個特別的對象，他會定義一個Person的唯一Id（第一個參數(shù)）以及他的關(guān)系鍵（第二個參數(shù)），這里，Organization ID（orgId）被選為一個Person的關(guān)系鍵，這意味著Persons數(shù)據(jù)會與他們所屬的Organizations的數(shù)據(jù)位于同一個節(jié)點(diǎn)上。

在定義這些業(yè)務(wù)實(shí)體以及預(yù)加載緩存數(shù)據(jù)之后，可以隨意執(zhí)行一個像下面這樣的SQL查詢，因為Person與他們的Organization是關(guān)系并置的，Ignite會確保返回一個完整的結(jié)果集。

SELECT * FROM Organization as org JOIN Person as p ON org.id = p.orgId

這個查詢的執(zhí)行流程是這樣的：

1. 查詢發(fā)起節(jié)點(diǎn)（mapper和reducer）會將查詢發(fā)給所有緩存數(shù)據(jù)的節(jié)點(diǎn)；

2. 從reducer收到查詢的所有節(jié)點(diǎn)會在本地執(zhí)行查詢，只會使用本地數(shù)據(jù)執(zhí)行關(guān)聯(lián)；

3. 這些節(jié)點(diǎn)會將結(jié)果集的一部分反饋給reducer；

4. reducer最后會匯總從所有遠(yuǎn)程節(jié)點(diǎn)收到的結(jié)果集，然后向發(fā)起節(jié)點(diǎn)發(fā)送一個最終的聚合的結(jié)果。

非并置的分布式關(guān)聯(lián)

如果同樣的查詢執(zhí)行在一個非關(guān)系并置的數(shù)據(jù)上，那么會得到一個不完整以及不一致的結(jié)果，原因是Apache Ignite在1.7.0之前的版本只會在本地數(shù)據(jù)上執(zhí)行查詢（就像上述流程的第二步描述的那樣）。 然而，在Ignite 1.7.0之后的版本不再是這樣的了，他會支持非并置的分布式關(guān)聯(lián)，這些關(guān)聯(lián)不再要求并置數(shù)據(jù)。 現(xiàn)在，會使用Person的真實(shí)Id作為緩存鍵，替代AffinityKey(id, orgId)，然后將orgId字段加入Person對象的內(nèi)部來執(zhí)行這兩個緩存的關(guān)聯(lián)，即使這些發(fā)生了改變，仍然會得到一個完整的結(jié)果，不用管實(shí)際上Person的數(shù)據(jù)是否與他們的Organization數(shù)據(jù)并置在一起，這是因為最新版的Ignite會以如下的流程執(zhí)行同樣的SQL查詢（上面提到的）：

1. 查詢發(fā)起節(jié)點(diǎn)（mapper和reducer）會將查詢發(fā)給所有緩存數(shù)據(jù)的節(jié)點(diǎn)；

2. 從reducer收到查詢的所有節(jié)點(diǎn)會在本地執(zhí)行查詢，但是使用本地數(shù)據(jù)和遠(yuǎn)程節(jié)點(diǎn)的數(shù)據(jù)進(jìn)行關(guān)聯(lián)（因為數(shù)據(jù)是全集群分布的）；

3. 這些節(jié)點(diǎn)會將結(jié)果集的一部分反饋給reducer；

4. reducer最后會匯總從所有遠(yuǎn)程節(jié)點(diǎn)收到的結(jié)果集，然后向發(fā)起節(jié)點(diǎn)發(fā)送一個最終的聚合的結(jié)果。

這里需要注意的一個重要的事是，由于查詢的特殊性，一個節(jié)點(diǎn)會向集群發(fā)送廣播來請求在第二步中丟失的數(shù)據(jù)，然而，現(xiàn)在也有一種方式來優(yōu)化，就是SQL引擎會為特定的關(guān)聯(lián)類型、典型的查詢將廣播切換為單播，下面的修改就會切換為單播模式：

SELECT * FROM Organization as org JOIN Person as p ON org._key = p.orgId

在這個查詢中，如果SQL引擎決定在Persons緩存加上Organizations上執(zhí)行查詢，然后引擎會使用org._key(s)向存儲Organizations緩存的節(jié)點(diǎn)發(fā)送單播請求，這里_key是Ignite SQL查詢中使用的一個特別的關(guān)鍵字，他會指向一個對象的緩存鍵/主鍵。基本上，因為引擎知道了它的緩存鍵/主鍵，會輕松地找到存儲條目的節(jié)點(diǎn)，用于多個緩存的關(guān)系鍵也是同樣的道理。

感謝各位的閱讀，以上就是“Apache Ignite1.7有哪些新特性”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Apache Ignite1.7有哪些新特性這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！