作者:Jeff Carpenter, InfoWorld
你的微服務(wù)架構(gòu)需要多種數(shù)據(jù)模型。你是應(yīng)該選擇混合持久化呢還是多模型數(shù)據(jù)庫(kù)?
在過(guò)去的十年,大規(guī)模的分布式系統(tǒng)呈現(xiàn)爆炸式增長(zhǎng)。這一趨勢(shì)促使在數(shù)據(jù)庫(kù)領(lǐng)域產(chǎn)生了一股巨大的創(chuàng)造力,這在軟件業(yè)的歷史上無(wú)疑是沒(méi)有先例的。其結(jié)果是誕生了一個(gè)健康和充滿(mǎn)競(jìng)爭(zhēng)的數(shù)據(jù)庫(kù)市場(chǎng),我們可以因此在大量的平臺(tái)中各取所需。但是我們應(yīng)該如何抉擇?
在本文中,我們將探討如何為根據(jù)應(yīng)用程序去選擇核實(shí)的數(shù)據(jù)庫(kù)模式。(是的,可以有一個(gè)以上的選擇?。覀円矔?huì)看看對(duì)數(shù)據(jù)模式的選擇可以幫助確定在數(shù)據(jù)層中將選用哪些技術(shù)。
云架構(gòu),NoSQL 和微服務(wù)架構(gòu)
隨著開(kāi)發(fā)人員開(kāi)始創(chuàng)建可擴(kuò)展的Web應(yīng)用,歷史上在數(shù)據(jù)架構(gòu)上占主導(dǎo)地位的關(guān)系型數(shù)據(jù)庫(kù),開(kāi)始顯示出很大的壓力。我們開(kāi)發(fā)了非常流行的社交應(yīng)用,并開(kāi)始將越來(lái)越多的設(shè)備連接到物聯(lián)網(wǎng)(IoT)。用戶(hù)大量的讀取和寫(xiě)入數(shù)據(jù)導(dǎo)致了必須擴(kuò)展數(shù)據(jù)層,從而出現(xiàn)了新型的數(shù)據(jù)庫(kù)來(lái)滿(mǎn)足這些高可擴(kuò)展性需求。
在許多情況下,這些新的數(shù)據(jù)庫(kù)“NoSQL”或“非關(guān)系”的解決方案,所基于的數(shù)據(jù)模型和傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)模型不同。NoSQL數(shù)據(jù)庫(kù)包括有文檔型、鍵值對(duì)型(key-value)、列式數(shù)據(jù)庫(kù)甚至圖數(shù)據(jù)庫(kù)。通常來(lái)說(shuō),這些數(shù)據(jù)庫(kù)犧牲了一些關(guān)系數(shù)據(jù)庫(kù)的常見(jiàn)的的特性,如強(qiáng)一致性、ACID事務(wù)特性和join連接。
與此同時(shí),和數(shù)據(jù)庫(kù)技術(shù)的變革一樣,在本世紀(jì)初的SOA(面向服務(wù)的架構(gòu)),正逐漸演變?yōu)槲⒎?wù)架構(gòu)的體系架構(gòu),許多企業(yè)也開(kāi)始逐漸拋棄重量級(jí)的SOA體系架構(gòu)如企業(yè)服務(wù)總線(xiàn)(ESB),并傾向使用“去中心化”的架構(gòu)方法。微服務(wù)架構(gòu)的魅力在于其開(kāi)發(fā)、管理和擴(kuò)展服務(wù)都是相對(duì)獨(dú)立的。這給了我們很多在實(shí)施方面的靈活性,包括基礎(chǔ)架構(gòu)技術(shù),如數(shù)據(jù)庫(kù)。
舉個(gè)例子,我們假設(shè)正在為微服務(wù)架構(gòu)做開(kāi)發(fā)工作,并期待著大規(guī)模的可擴(kuò)展性的需求。無(wú)論這個(gè)項(xiàng)目是一個(gè)新的應(yīng)用還是對(duì)現(xiàn)有應(yīng)用的重構(gòu),我們都有機(jī)會(huì)針對(duì)數(shù)據(jù)庫(kù)做出新的選擇。
混合持久化(Polyglot persistence)
微服務(wù)架構(gòu)風(fēng)格的一個(gè)關(guān)鍵的好處,是持久性的封裝。我們可以根據(jù)每個(gè)服務(wù)的需要,去選擇不同的持久化技術(shù)。根據(jù)每種數(shù)據(jù)類(lèi)型的特點(diǎn)而去選擇數(shù)據(jù)存儲(chǔ)的方法,被稱(chēng)為混合持久化,這一術(shù)語(yǔ)起初是由Martin Fowler等人推廣起來(lái)的?;旌铣志没臀⒎?wù)架構(gòu)可謂是天作之合。
下圖中,展示了一系列的微服務(wù),以及我們?nèi)绾螢槊總€(gè)服務(wù)選擇不同的數(shù)據(jù)模式。我不想在本文中,為每種類(lèi)型的數(shù)據(jù)庫(kù)去選擇合適的用例。我的意圖是要突出各類(lèi)型數(shù)據(jù)庫(kù)的優(yōu)勢(shì),以及為什么混合持久化的方法是值得稱(chēng)道的.
其中,開(kāi)發(fā)服務(wù)A的團(tuán)隊(duì),因?yàn)樵摲?wù)是基于大規(guī)模數(shù)據(jù)管理的核心應(yīng)用,可能使用如Apache Cassandra這樣的表格模型數(shù)據(jù)庫(kù)。例如,一個(gè)零售應(yīng)用庫(kù)存應(yīng)用,可能很適合使用Apache Cassandra。Cassandra提供了一系列協(xié)調(diào)機(jī)制工具,如可調(diào)一致,批處理和輕量級(jí)的事務(wù)機(jī)制,可以作為完整ACID事務(wù)機(jī)制的替代。
服務(wù)B支持用眾所周知的關(guān)鍵字查找值的方式,例如針對(duì)產(chǎn)品目錄的描述性數(shù)據(jù)。對(duì)于鍵值存儲(chǔ)模型來(lái)說(shuō),這是一個(gè)很好的例子,在這里,我們通過(guò)一個(gè)眾所周知的鍵值(如產(chǎn)品ID)查找一系列的數(shù)據(jù)。很多內(nèi)存緩存都使用鍵值對(duì)數(shù)據(jù)模式去支持大規(guī)模的快速讀取。
服務(wù)C可能主要關(guān)注半結(jié)構(gòu)化內(nèi)容,例如Web站點(diǎn)的表單或頁(yè)面,而文檔存儲(chǔ)可能非常適合該類(lèi)型數(shù)據(jù)。文檔存儲(chǔ)與鍵值存儲(chǔ)有許多相似之處,但是一個(gè)關(guān)鍵的區(qū)別是文檔型數(shù)據(jù)支持?jǐn)?shù)據(jù)上增加結(jié)構(gòu),例如對(duì)特定屬性進(jìn)行索引以支持快速檢索。
服務(wù)D可能涉及數(shù)據(jù)之間的復(fù)雜關(guān)系導(dǎo)航,例如客戶(hù)數(shù)據(jù)和與組織中各部門(mén)的客戶(hù)聯(lián)系歷史數(shù)據(jù)。這可能涉及其他服務(wù)所擁有的數(shù)據(jù)類(lèi)型之間的關(guān)系。這是一個(gè)有趣的案例,因?yàn)樗_(kāi)始與上面提到的服務(wù)有各自的數(shù)據(jù)類(lèi)型的約束相反。在這種情況下,你可以選擇為你的服務(wù)創(chuàng)建一個(gè)具有對(duì)底層表的只讀訪問(wèn)的圖,然后通過(guò)這個(gè)“前門(mén)”處理所有的變化——即通過(guò)這個(gè)“前門(mén)”去調(diào)用那些“擁有”這些數(shù)據(jù)類(lèi)型的其他服務(wù)的API。
最后,我們可能還有一個(gè)使用關(guān)系數(shù)據(jù)庫(kù)技術(shù)的遺留系統(tǒng)或服務(wù),或者我們有一個(gè)服務(wù)來(lái)管理那些數(shù)據(jù)量較少,或者不經(jīng)常變更的數(shù)據(jù)。關(guān)系數(shù)據(jù)庫(kù)可能完全適合于這些場(chǎng)景。
單個(gè)服務(wù)是否應(yīng)該使用混合持久化?
也有可能的是,我們可以設(shè)計(jì)一個(gè)服務(wù),這個(gè)服務(wù)需要多種數(shù)據(jù)庫(kù)支撐。例如,我們可以創(chuàng)建一個(gè)使用鍵值存儲(chǔ)模式作為索引的酒店服務(wù),在酒店名稱(chēng)和ID之間實(shí)現(xiàn)映射,而存將關(guān)于酒店的描述性數(shù)據(jù)存儲(chǔ)在Cassandra中。
注意,名稱(chēng)映射到ID可以在Cassandra中采用規(guī)范化的設(shè)計(jì)方法去實(shí)現(xiàn),其中一個(gè)單獨(dú)表去維護(hù)名稱(chēng)至ID的映射關(guān)系。這使用了更多的存儲(chǔ)空間,但降低了管理單獨(dú)鍵值存儲(chǔ)的操作復(fù)雜性。
這是我推薦的做法-?針對(duì)某個(gè)微服務(wù),只要可行,就應(yīng)該堅(jiān)持使用單一數(shù)據(jù)模型(數(shù)據(jù)庫(kù))。如果你發(fā)現(xiàn)一種情況,認(rèn)為單個(gè)服務(wù)需要兩個(gè)不同數(shù)據(jù)庫(kù)支撐,那么請(qǐng)考慮該服務(wù)的粒度是否可能變得太大。你可能需要考慮將該服務(wù)拆分為較小的服務(wù)。
混合持久化局限性的權(quán)衡
混合持久化的主要缺點(diǎn)在于支持多種技術(shù)的成本,無(wú)論是在最初的開(kāi)發(fā)階段和將來(lái)的運(yùn)營(yíng)方面。
主要的開(kāi)發(fā)成本,是在需要培訓(xùn)每個(gè)開(kāi)發(fā)人員去掌握每個(gè)新的數(shù)據(jù)庫(kù)技術(shù)。這是非常重要的,尤其是在開(kāi)發(fā)人員頻繁流動(dòng)團(tuán)隊(duì)中。
另一個(gè)成本是支持多個(gè)數(shù)據(jù)庫(kù)的操作成本。這會(huì)成為一個(gè)問(wèn)題,尤其是當(dāng)數(shù)據(jù)庫(kù)是集中管理,并且團(tuán)隊(duì)必須在多種技術(shù)的掌握上維持高水平,但這在DevOps環(huán)境下,該問(wèn)題并不會(huì)太突出,因?yàn)殚_(kāi)發(fā)團(tuán)隊(duì)需要支持他們?cè)谏a(chǎn)環(huán)境中選擇的數(shù)據(jù)庫(kù)。
多模型數(shù)據(jù)庫(kù)(Multi Model Databases)
作為另外的選擇方案或混合持久化模式的補(bǔ)充, 數(shù)據(jù)庫(kù)廠商已經(jīng)開(kāi)始建立和推廣多模型的數(shù)據(jù)庫(kù)。術(shù)語(yǔ)“模型”指的是數(shù)據(jù)存儲(chǔ)所提供的核心抽象,如表(關(guān)系和非關(guān)系)、列存儲(chǔ)、鍵值、文檔或圖。我們可以將一個(gè)多模型應(yīng)用程序看作一個(gè)使用多個(gè)數(shù)據(jù)存儲(chǔ)類(lèi)型的應(yīng)用程序,而多模型數(shù)據(jù)庫(kù)是支持多個(gè)抽象模型的數(shù)據(jù)庫(kù)。
DataStax企業(yè)版(DSE)是多模型數(shù)據(jù)庫(kù)的典型例子,它核心支持Cassandra的分區(qū)行存儲(chǔ)(表格)模型,同時(shí)也支持基于在其之上的圖的抽象層(DSE圖)。DSE在核心模型之上構(gòu)建對(duì)應(yīng)的鍵值和文檔模型也是很簡(jiǎn)單的,如下圖所示。這樣,我們可以修改上面的混合持久化的方法,從而利用一個(gè)基礎(chǔ)數(shù)據(jù)庫(kù)引擎為我們所有的服務(wù)提供對(duì)應(yīng)的服務(wù),而使用單獨(dú)的Cassandra keyspaces在不同服務(wù)擁有的數(shù)據(jù)間維護(hù)清晰的邊界。
下面是它能實(shí)現(xiàn)的功能:
[list]
Cassandra,例如:
代碼
多模型數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)和限制
在考慮是否投資使用多模型數(shù)據(jù)庫(kù)(或你已經(jīng)在使用的數(shù)據(jù)庫(kù)的多模型的特性)時(shí),你要考慮我們前文討論的關(guān)于混合持久化中,同樣的開(kāi)發(fā)和運(yùn)營(yíng)成本的問(wèn)題。
使用多模型數(shù)據(jù)庫(kù)可以讓運(yùn)營(yíng)變得簡(jiǎn)單。即使不同的開(kāi)發(fā)團(tuán)隊(duì)使用不同的API和不同的交互模式和后端數(shù)據(jù)庫(kù)平臺(tái)打交道,我們也只需要管理一個(gè)平臺(tái)而已,從而提高了效率。
在選擇多模型數(shù)據(jù)庫(kù)時(shí)要考慮的一個(gè)問(wèn)題是如何支持各種模型。一種常見(jiàn)的方法,是基于單一的原生的基礎(chǔ)模型的數(shù)據(jù)庫(kù)引擎,而其他模型都是構(gòu)建在其之上。分層數(shù)據(jù)模型更能展現(xiàn)底層基本模型的特性。
例如,ThoughtWorks技術(shù)雷達(dá)第16期中,討論了基于Cassandra構(gòu)建的DSE圖數(shù)據(jù)庫(kù)的特性,并且也提到其中需要權(quán)衡的內(nèi)容:
引用
基于Cassandra 構(gòu)建的DSE圖數(shù)據(jù)庫(kù)定位是大規(guī)模的數(shù)據(jù)集,相比之下我們長(zhǎng)期喜愛(ài)的Neo4j開(kāi)始表現(xiàn)出一定的局限性。這是需要取舍的;比如,你會(huì)失去了ACID的事務(wù)特性和Neo4j運(yùn)行時(shí)的模式自由的特性,但卻可以訪問(wèn)Cassandra的基礎(chǔ)表,以及針對(duì)分析工作負(fù)載和Spark的整合,還有強(qiáng)大的TinkerPop/Gremlin查詢(xún)語(yǔ)言可以使用,這的確是一個(gè)值得考慮的選擇。
如果考慮Web應(yīng)用中的各種數(shù)據(jù)類(lèi)型,你可能會(huì)發(fā)現(xiàn)不同的數(shù)據(jù)類(lèi)型對(duì)一致性有不同的需求,而且實(shí)際需要立即一致性的數(shù)據(jù)類(lèi)型數(shù)量相對(duì)較少。
上面引用的ThoughtWorks的觀點(diǎn)中,還提到了在考慮多模型數(shù)據(jù)庫(kù)中另一個(gè)重要的因素?-?在不同的模型和數(shù)據(jù)引擎間的整合和交互問(wèn)題,以及為訪問(wèn)數(shù)據(jù)的各種操作和分析的用例。DSE支持通過(guò)Spark(DSE分析)訪問(wèn)圖數(shù)據(jù)以進(jìn)行數(shù)據(jù)分析,并且DSE搜索引擎提供了針對(duì)DSE數(shù)據(jù)庫(kù)中的數(shù)據(jù)創(chuàng)建各種查詢(xún)索引的能力。
微服務(wù)數(shù)據(jù)模型操作的四個(gè)步驟
既然我們已經(jīng)探討混合持久化和多模型兩種方式的優(yōu)缺點(diǎn),我們應(yīng)該如何去決定哪些數(shù)據(jù)模型適用于大規(guī)模可擴(kuò)展的微服務(wù)應(yīng)用呢?可以按照以下步驟:
識(shí)別你的應(yīng)用程序中主要的數(shù)據(jù)類(lèi)型,為其中每種類(lèi)型創(chuàng)建一個(gè)服務(wù),并讓每個(gè)服務(wù)掌控相應(yīng)的持久層。在可能的情況下,為所有服務(wù)都使用多模型數(shù)據(jù)庫(kù),允許服務(wù)在與數(shù)據(jù)交互的模型中是不相同的。用Tabular(例如DSE數(shù)據(jù)庫(kù))作為網(wǎng)絡(luò)水平的可擴(kuò)展性和可用性的主要模型,然后根據(jù)需要在此之上構(gòu)建分層的鍵值對(duì)和文檔數(shù)據(jù)模型。請(qǐng)務(wù)必考慮在操作和分析用例中訪問(wèn)數(shù)據(jù)的各種方法,以便提前計(jì)劃如何將搜索索引和復(fù)制等特性用于數(shù)據(jù)分析中心。用圖的方法去表示(即DSE圖)高度關(guān)聯(lián)的數(shù)據(jù),特別是在實(shí)體之間的關(guān)系有多個(gè)或多個(gè)屬性,并且數(shù)量比實(shí)體自己的屬性多的時(shí)候,或者需要在相同的實(shí)體之間捕捉多對(duì)多的關(guān)系的時(shí)候。在不需要變更的情況下,保留關(guān)系數(shù)據(jù)庫(kù)技術(shù)中的遺留投資。例如,當(dāng)你的案例是需要大規(guī)模、低延遲和高可用性的時(shí)候,那就使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)吧。我希望本文為讀者提供了一個(gè)有用的框架,來(lái)考慮在應(yīng)用程序中如何和怎么樣去支持多數(shù)據(jù)模型,以及何時(shí)考慮使用多模型數(shù)據(jù)庫(kù)。
- 特朗普宣布200億美元投資計(jì)劃,在美國(guó)多地建設(shè)數(shù)據(jù)中心
- 工信部:“點(diǎn)、鏈、網(wǎng)、面”體系化推進(jìn)算力網(wǎng)絡(luò)工作 持續(xù)提升算網(wǎng)綜合供給能力
- 2025年超融合基礎(chǔ)設(shè)施的4大趨勢(shì)
- 2025年將影響數(shù)據(jù)中心的5個(gè)云計(jì)算趨勢(shì)
- 80萬(wàn)輛大眾汽車(chē)因AWS云配置錯(cuò)誤導(dǎo)致數(shù)據(jù)泄露,包含“高精度”位置記錄
- 名創(chuàng)優(yōu)品超4000家門(mén)店接入“碰一下”支付,引爆年輕消費(fèi)熱潮
- 免稅店也能用“碰一下”支付了!中免海南免稅店:碰一下就優(yōu)惠
- 報(bào)告:人工智能推動(dòng)數(shù)據(jù)中心系統(tǒng)支出激增25%
- 密態(tài)計(jì)算技術(shù)助力農(nóng)村普惠金融 螞蟻密算、網(wǎng)商銀行項(xiàng)目入選大數(shù)據(jù)“星河”案例
- 專(zhuān)利糾紛升級(jí)!Netflix就虛擬機(jī)專(zhuān)利侵權(quán)起訴博通及VMware
免責(zé)聲明:本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請(qǐng)進(jìn)一步核實(shí),并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后,將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí),溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。