作者：Jeff Carpenter

近十年來，大規(guī)模分布式系統(tǒng)得到了爆炸式增長，已經(jīng)產(chǎn)生了一股可以說是對整個軟件業(yè)開先河式的，數(shù)據(jù)庫界的創(chuàng)意旋風(fēng)。市場上也涌現(xiàn)了大量的頗具競爭力的數(shù)據(jù)庫平臺。

在本文中，我們將探討如何為您的應(yīng)用去選擇合適的數(shù)據(jù)庫模型（是的，完全可以選擇不止一個?。?。我們也會討論到這些數(shù)據(jù)模型的選擇將如何幫助您去確定數(shù)據(jù)層面的各種技術(shù)。

一、云架構(gòu)，NoSQL和微服務(wù)

在軟件開發(fā)人員開始創(chuàng)建Web架構(gòu)的應(yīng)用時，那些在歷史上一直主導(dǎo)著我們多年的關(guān)系型數(shù)據(jù)庫架構(gòu)，已經(jīng)開始表現(xiàn)出“壓力山大”了。特別是在我們開發(fā)那些被頻繁使用的社交應(yīng)用，和將越來越多的設(shè)備連接到物聯(lián)網(wǎng)（IOT）的時候，客戶端大量地讀取和寫入數(shù)據(jù)導(dǎo)致了數(shù)據(jù)層面的擴展需求。而與此同時，為了滿足這些高擴展性的需求，新的數(shù)據(jù)庫類型隨之出現(xiàn)。

在許多情況下，這些新的數(shù)據(jù)庫是“非結(jié)構(gòu)化查詢語言（NoSQL）”或“非關(guān)系型”的數(shù)據(jù)模型解決方案。它們并非顯性的關(guān)系模型，如文檔、鍵-值、面向整列的、甚至是圖表數(shù)據(jù)庫。通常，這些數(shù)據(jù)庫犧牲了一些在傳統(tǒng)關(guān)系型數(shù)據(jù)庫上為我們所熟悉的特性，如：強一致性、ACID事務(wù)和各種連接（joins）。

同時，作為革命性的數(shù)據(jù)庫技術(shù)，SOA（面向服務(wù)的架構(gòu)）已經(jīng)日趨向微服務(wù)架構(gòu)的風(fēng)格進行發(fā)展，許多組織開始摒棄諸如企業(yè)服務(wù)總線（ESB）的重量級SOA架構(gòu)，而改用更為分散的實現(xiàn)方法。微服務(wù)架構(gòu)的吸引力在于其獨立的開發(fā)、管理和擴展各種服務(wù)的能力。這使得我們在考慮數(shù)據(jù)庫架構(gòu)實現(xiàn)等方面的技術(shù)上，具有大量的實施選擇靈活性。

舉例而言，假設(shè)我們根據(jù)一項大規(guī)?？蓴U展性的需求，正在從事一個重要的微服務(wù)架構(gòu)的開發(fā)。那么，無論該項目是一項新的應(yīng)用，還是對現(xiàn)有應(yīng)用的重構(gòu)，我們都有機會來選擇新的數(shù)據(jù)庫。

1.混合持久化（Polyglot persistence）

微服務(wù)模式的一項優(yōu)勢是封裝的持久性，我們可以自由地根據(jù)每個服務(wù)的需求來選擇不同的持久化技術(shù)。Martin Fowler等人提出的混合持久化這一術(shù)語，特指根據(jù)不同的數(shù)據(jù)類型來選擇數(shù)據(jù)存儲的方法，可以說混合持久化天生就十分契合微服務(wù)。

下面的例圖顯示了一組微服務(wù)，我們該如何為每一項服務(wù)來選擇使用不同的數(shù)據(jù)模型呢？在此，我不一一列舉每種數(shù)據(jù)庫類型的適當(dāng)用例，只會突出這些數(shù)據(jù)庫類型和混合方法的優(yōu)勢所在。

將混合持久化應(yīng)用到微服務(wù)上。

開發(fā)服務(wù)A的小組可能會選擇使用表格型數(shù)據(jù)庫（tabular database），如Apache Cassandra，因為它能大規(guī)模地管理核心應(yīng)用的數(shù)據(jù)。例如，零售應(yīng)用的庫存類數(shù)據(jù)可能就非常適合于Cassandra的表格形式。Cassandra提供了一套協(xié)調(diào)機制的工具集，包括能夠批量調(diào)整一致性，和作為全面ACID事務(wù)替代品的輕量級事務(wù)等。

服務(wù)B可能只需要支持通過well-known鍵來查詢參考值，這樣簡單的語義，比如說一個產(chǎn)品編錄的描述性數(shù)據(jù)。這是一個很好的鍵-值（key-value）存儲的案例，我們可以通過產(chǎn)品ID的well-known鍵-值來查找一個BLOB（二進制對象文件的容器）類型的數(shù)據(jù)。那么大量的內(nèi)存空間會被用來緩存鍵-值類型的數(shù)據(jù)，從而支持大規(guī)模、且超快速地讀取訪問。

服務(wù)C主要考慮的是提供半結(jié)構(gòu)化的內(nèi)容，例如：網(wǎng)站的網(wǎng)頁或表格，以及文檔存儲，這些類型的數(shù)據(jù)都是非常適合的。文檔的存儲有“許多鍵-值類型相似，僅有某個鍵不同”的數(shù)據(jù)結(jié)構(gòu)，例如只要索引某些特殊屬性項，便可加快各種搜索的能力。

服務(wù)D則涉及到導(dǎo)航各種數(shù)據(jù)間的復(fù)雜關(guān)系，例如：客戶數(shù)據(jù)與組織內(nèi)不同部門的客戶聯(lián)系人之間的歷史數(shù)據(jù)。這可能潛在地涉及到：各種不同服務(wù)所擁有的數(shù)據(jù)類型之間的各種關(guān)系。比如說在這種情況下，您可以選擇讓您的服務(wù)創(chuàng)建一個對于各種底層表格都是只讀的視圖，然后通過調(diào)用其他“擁有著”自身數(shù)據(jù)類型的服務(wù)API這樣的“front door”，來過濾實現(xiàn)任何預(yù)期的轉(zhuǎn)換。

最后，我們還可能會有一些使用著關(guān)系型技術(shù)的傳統(tǒng)系統(tǒng)與服務(wù)，或者我們有一個管理著少量且不經(jīng)常更改的數(shù)據(jù)服務(wù)。那么關(guān)系型數(shù)據(jù)庫對于此類用例就是再好不過的了。

2.單獨的服務(wù)需要混合嗎？

也有一種可能：我們設(shè)計出一個放置在多數(shù)據(jù)庫之上的服務(wù)。例如說，我們可以創(chuàng)建一個使用的鍵-值存儲索引的酒店服務(wù)，它映射名稱和ID之間的關(guān)系。同時它用Cassandra的表格樣式來存儲關(guān)于酒店的描述性數(shù)據(jù)。

一個混合服務(wù)？

注意：使用非規(guī)范化的設(shè)計方法，同樣可以在Cassandra中實現(xiàn)名稱與ID的映射，當(dāng)然您需要用一張單獨的表格來維持名稱與ID的映射。這樣雖然會用到更多的存儲空間，但是簡化了我們在管理一個單獨的鍵-值存儲操作上的復(fù)雜性。

所以我的建議是：只要可行，完全可以把一個給定的微服務(wù)與一個單一的數(shù)據(jù)模型（和數(shù)據(jù)庫）相連接。如果您碰到需要將單一的服務(wù)放置在兩個不同的數(shù)據(jù)庫之上的情況，請判斷該服務(wù)的范圍是否過大。如果太大，您可能就需要考慮將其拆分成多個更小的服務(wù)了。

3.混合持久化的限制與利弊

混合持久化的主要劣勢是：在最初化開發(fā)和運營方面，需要支持多種技術(shù)的成本。

開發(fā)的成本主要來自于培訓(xùn)各個開發(fā)人員熟悉每種新的數(shù)據(jù)庫技術(shù)的成本。如果您的開發(fā)團隊流動性較大的話，這種劣勢會更加明顯。

而另一個弊端是支持多個數(shù)據(jù)庫的運營成本。如果數(shù)據(jù)庫的管理是集中化的，并且整體團隊必須對多種技術(shù)保持較高的維護水平時，這就可能會出現(xiàn)問題。但是當(dāng)開發(fā)團隊僅支持他們已選定的生產(chǎn)環(huán)境所用到的數(shù)據(jù)庫，從而形成了真正的Devops運作模式時，該問題會得到適當(dāng)?shù)木徑狻?/p>

4.多模型數(shù)據(jù)庫

數(shù)據(jù)庫提供商已經(jīng)開始著手打造與提升一些多模型的數(shù)據(jù)庫，作為混合持久化方法的一種替代或補充了。術(shù)語“模型”是指由諸如表格（包括關(guān)系和非關(guān)系型）、列存儲、鍵-值、文檔或圖表之類的數(shù)據(jù)存儲所提供的抽象模型。我們可以理解為：多模型應(yīng)用使用的是一種類型以上的數(shù)據(jù)存儲，而多模型數(shù)據(jù)庫則能夠支持多種抽象。

DataStax Enterprise（DSE）是一個多模型數(shù)據(jù)庫的例子，其核心使用一種建立在頂端圖表的抽象（DSE圖表），來支持Cassandra分區(qū)的行存儲（表格）模式。如下圖所示，在此核心模型上創(chuàng)建您自己的鍵-值和各種文檔類型的抽象是非常簡單的。通過這種方式，我們可以修改上述的混合方法，利用單一的底層數(shù)據(jù)庫引擎來提供我們的所有服務(wù)。與此同時，我們還可以使用單獨的Cassandra鍵值空間，來維持那些由不同服務(wù)所擁有的數(shù)據(jù)之間的清晰界限。

與DataStax Enterprise交互，作為一個多模型的數(shù)據(jù)庫。

我們下面來看看它是如何工作的：

表格：服務(wù)A之類的主要應(yīng)用服務(wù)可以使用Cassandra的查詢語言（CQL），來與DSE數(shù)據(jù)庫直接進行交互。

鍵-值：雖然Apache和DataStax的Cassandra版本都無法提供一個明確的鍵-值A(chǔ)PI，但是像服務(wù)B之類的服務(wù)卻能夠通過設(shè)計來限制表格只與Cassandra互動實現(xiàn)鍵-值的存儲。例如：

CREATE?TABLE?hotel.hotels?(?key?uuid?PRIMARY?KEY,?value?text);?//?or?if?you?prefer,?“blob”

文件：通過各種JSON文件，Cassandra能夠支持文檔類型的交互，這可以被用于服務(wù)C之類的服務(wù)。注意：因為Cassandra的確需要有表的schema模式，因此您不能插入任意的JSON來隨便定義新的列，也就是說通常需要具有與文檔數(shù)據(jù)庫相關(guān)聯(lián)的特性。

圖表：對于像服務(wù)D之類高度支持?jǐn)?shù)據(jù)互連的服務(wù)來說，DSE圖表是一個高度可擴展的圖表數(shù)據(jù)庫，它直接建立在DSE數(shù)據(jù)庫之上。DSE圖表通過Apache TinkerPop 項目來支持強大的、且易于表現(xiàn)的Gremlin API。

5.多模型數(shù)據(jù)庫的優(yōu)勢和局限性

在考慮是否要使用多模型數(shù)據(jù)庫的時候（或使用你已有數(shù)據(jù)庫的多模型功能時），你需要兼顧考慮我們上述所討論的有關(guān)混合持久化方法所帶來的開發(fā)和運營成本。

使用多模型數(shù)據(jù)庫可以簡化運營。無論是不同的開發(fā)團隊使用不同的API，還是不同的后端數(shù)據(jù)庫平臺交互模式，我們都會從只需要管理單一的平臺來受益。

在選擇多模型數(shù)據(jù)庫時，需要考慮的一個方面就是：各種模型如何能夠被支持。一種常用的處理方式是：一個基于單一本地的底層模型與其上面分層的其他模型共同組成一個數(shù)據(jù)庫引擎。分層的數(shù)據(jù)模型用于展示其底層主模型的各種特征。

例如，在ThoughtWorks的技術(shù)雷達(dá)第16卷（Technology Radar Vol. 16）（https://assets.thoughtworks.com/assets/technology-radar-vol-16-en.pdf）中，就討論展示了在Cassandra頂端分層的DSE圖表模型的特性和所涉及的取舍：

我們所長期鐘愛和使用的Neo4j（譯者注：Neo4j是一種高性能的NOSQL類型圖表數(shù)據(jù)庫，它將結(jié)構(gòu)化數(shù)據(jù)存儲在網(wǎng)絡(luò)中而不是本地表里。）已經(jīng)在大型的數(shù)據(jù)集類型中逐漸顯露出了局限性，而建立在Cassandra頂端的DSE圖表則應(yīng)運而生。

當(dāng)然，這種模式也有其自己的取舍，例如：您會失去ACID事務(wù)和Neo4j的獨立于架構(gòu)運行（run-time schema-free）特性；但是DSE通過訪問底層的Cassandra各種表格，Spark對分析負(fù)載的集成，以及強大的TinkerPop/Gremlin查詢語言，都使得它還是很值得考慮和選擇的。

如果您在自己的Web架構(gòu)應(yīng)用中考慮使用不同的數(shù)據(jù)類型，那么您可能就會發(fā)現(xiàn)到：不同的數(shù)據(jù)類型有著不同的一致性需求，而實際需要立即進行一致化的數(shù)據(jù)類型并不多。

另一個需要重點考慮的是：多模型的空間問題，即不同數(shù)據(jù)庫模型和引發(fā)的集成與交互，以及訪問數(shù)據(jù)的各種操作和分析用例。DSE支持通過Spark（DSE分析）來訪問圖表數(shù)據(jù)以實現(xiàn)其分析的目的，而DSE搜索則提供了用于創(chuàng)建那些存儲在DSE數(shù)據(jù)庫中數(shù)據(jù)的各種搜索索引的能力。

二、微服務(wù)數(shù)據(jù)模型的四步驟

既然我們已經(jīng)了解了混合與多模型方法的各類優(yōu)點，那么我們應(yīng)該如何為大規(guī)模的微服務(wù)應(yīng)用來選定數(shù)據(jù)模型呢？請參考下列的步驟：

我希望上述內(nèi)容能夠為您在思考如何為自己的應(yīng)用程序提供多模型支持，以及何時、何處用到多模型數(shù)據(jù)庫的時候提供一個實用的框架。

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。