Apache Ignite1.7有哪些新特性

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

Apache Ignite 1.7的新特性-非并置的分布式關聯

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

基于關系并置的關聯

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

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

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

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

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

這個查詢的執行流程是這樣的：

1. 查詢發起節點（mapper和reducer）會將查詢發給所有緩存數據的節點；

2. 從reducer收到查詢的所有節點會在本地執行查詢，只會使用本地數據執行關聯；

3. 這些節點會將結果集的一部分反饋給reducer；

4. reducer最后會匯總從所有遠程節點收到的結果集，然后向發起節點發送一個最終的聚合的結果。

非并置的分布式關聯

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

1. 查詢發起節點（mapper和reducer）會將查詢發給所有緩存數據的節點；

2. 從reducer收到查詢的所有節點會在本地執行查詢，但是使用本地數據和遠程節點的數據進行關聯（因為數據是全集群分布的）；

3. 這些節點會將結果集的一部分反饋給reducer；

4. reducer最后會匯總從所有遠程節點收到的結果集，然后向發起節點發送一個最終的聚合的結果。

這里需要注意的一個重要的事是，由于查詢的特殊性，一個節點會向集群發送廣播來請求在第二步中丟失的數據，然而，現在也有一種方式來優化，就是SQL引擎會為特定的關聯類型、典型的查詢將廣播切換為單播，下面的修改就會切換為單播模式：

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

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

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