在上一篇文章中，回顧和總結了Cassandra中使用的查詢驅動數據模型（或者說非常規數據模型）方法論的缺陷。事實證明，如果不對查詢有深入的了解，通過該方法論將無法開發高效的應用。實際上，這種場景的應用架構上會變得更加的復雜，難于維護，并且會造成很大的數據冗余。

此外，這個問題通常會被這樣的觀點掩蓋：“如果想要擴展性、速度以及高可用性，那么就得準備存儲多份數據，并且犧牲SQL和強一致性。”，這個論調十年前可能是正確的，但是現在完全錯誤！

沒那么夸張，我們選擇了另一個ASF成員，Apache Ignite。在本文中，會講解基于Ignite的應用架構，然后衡量它的維護成本。

我們選擇的應用仍然是跟蹤所有廠商生產的車輛，然后了解每個單一廠商的產能，如果看過第一篇文章，那么應該知道關系模型如下：

下一步，可以使用Ignite的CREATE TABLE命令創建這三個表，然后運行由SQL驅動的應用了么？不一定，如果不需要對存儲于不同表中的數據進行關聯操作，那么是可以的。但是根據前文，前提是應用需要支持兩種關聯的查詢：

1. Q1：獲取一個廠商在特定的時間段內生產的車型。
2. Q2：獲取一個廠商特定車型的產量。

在Cassandra的案例中，我們為每個查詢創建了一張表規避了關聯的問題，那么用Ignite，是不是還要經歷同樣的過程？完全不用。事實上，Ignite的非并置的關聯已經完全可用，如果三個表已經建好了，那么不需要什么額外的工作。但是，這沒有比并置的高效和快速。因此，首先要多學習一下關系并置，然后了解這個概念在Ignite中是如何使用的。

基于并置關聯的數據模型

關系并置在Ignite（還有其他的分布式數據庫，比如Google Spanner以及MemSQL）中是一個強大的概念，它可以在以一個集群節點上存儲相關的數據。那么哪些數據是相關的呢？尤其是在關系數據庫的背景下，這非常簡單，只需要在業務對象之間標示一個父子關系，在CREATE TABLE語句中指定一個關系鍵就可以了，剩下的就交給Ignite了！

還是拿車輛和廠商的應用舉例，使用廠商作為父實體，車輛作為子實體是合理的。比如，按照這樣配置好之后，某個廠商生產的所有車輛數據都會存儲于同一個節點上，如下圖所示：

如圖所示，豐田生產的車輛都存儲于節點1，而福特生產的車輛都存儲于節點2，這就是關系并置，車輛都會存儲于對應的廠商所在的節點上。

要做到這樣的數據分布，Vendor表的SQL定義如下：

CREATE TABLE Vendor (id INT PRIMARY KEY,name VARCHAR,address VARCHAR
);

廠商數據會在整個集群中隨機地分布，Ignite會使用主鍵列計算廠商數據所在的節點。 下一個是Car表：

CREATE TABLE Car (id INT,vendor_id INT,model VARCHAR,year INT,price float,PRIMARY KEY(id, vendor_id)
) WITH "affinityKey=vendor_id";

車輛表有一個affinityKey參數，配置為vendor_id列，它告訴Ignite，車輛存儲于vendor_id對應的集群節點。

在Production表上重復同樣的過程，它的數據也是存儲于vendor_id對應的集群節點上,如下：

CREATE TABLE Production (id INT,car_id INT,vendor_id INT,country VARCHAR,total INT,year INT,PRIMARY KEY(id, car_id, vendor_id)
) WITH "affinityKey=vendor_id";

這樣數據模型就建完了,下一步就進入應用的代碼，然后開發必要的查詢。

帶關聯的SQL查詢

Ignite集群可以使用我們熟悉的SQL進行查詢，它支持分布式的SQL關聯以及二級索引。 Ignite支持兩種類型的關聯：并置和非并置。假定要關聯的表已經并置，并且本地數據全部可用，那么并置的關聯會避免數據(關聯所需的）的移動,這是在分布式數據庫中效率最高、性能最好的。如果部分表無法實現關系并置，但是還需要進行關聯，那么非并置的關聯就是一個備份計劃。這種類型的關聯速度較慢，因為在關聯時它需要在集群節點間進行數據的移動。

之前，已經配置好了Vendor、Car和Production表，下一步就是利用并置關聯的優勢，為Q1寫一個SQL：

SELECT c.model, p.country, p.total, p.year FROM Vendor as v
JOIN Production as p ON v.id = p.vendor_id
JOIN Car as c ON c.id = p.car_id
WHERE v.name = 'Ford Motor' and p.year >= 2017
ORDER BY p.year;

還能更快么？當然能。下面為Vendor.name和Production.year列定義二級索引：

CREATE INDEX vendor_name_id ON Vendor (name);
CREATE INDEX prod_year_id ON Production (year);

針對Q2的查詢也不需要額外的工作:

SELECT p.country, p.total, p.year FROM Vendor as v
JOIN Production as p ON v.id = p.vendor_id
JOIN Car as c ON c.id = p.car_id
WHERE v.name = 'Ford Motor' and c.model = 'Explorer';

現在，如果老板要求增加一個新特性時，很快就能構造出一套新的SQL滿足他。 完成！作為比較，如果要支持Q2，可以看看基于Cassandra的架構是怎么搞的。

架構簡化：任務完成！

Ignite的基于關系并置的數據模型，針對Cassandra的基于查詢驅動的模型有如下的優點：

• 應用的數據層基于熟悉的關系模型進行建模，易于維護；
• 數據使用標準的SQL語法進行訪問；
• 關系并置提供了現代分布式數據庫的更多好處：
  • 高效和高性能的分布式關聯；
  • 并置計算;

使用Ignite替代Cassandra，簡化的軟件架構并不是唯一的好處，過段時間，還會有關于強一致性和內存極性能方面的想法。

本文譯自Denis Magda的博客。