過(guò)去十年見(jiàn)證了分布式數(shù)據(jù)庫(kù)的崛起。不僅通過(guò)本地集群來(lái)實(shí)現(xiàn)負(fù)載均衡，并提供高可用性，還具有數(shù)據(jù)中心內(nèi)的機(jī)架感知等屬性。專為云而設(shè)計(jì)的分布式數(shù)據(jù)庫(kù)，可以跨越可用性區(qū)域，通過(guò)編排技術(shù)，支持公有云、私有云、混合云部署。近年來(lái)，市面上出現(xiàn)了大量專為分布式數(shù)據(jù)庫(kù)部署而設(shè)計(jì)的新數(shù)據(jù)庫(kù)系統(tǒng)，以及在初始設(shè)計(jì)中添加了分布式架構(gòu)組件的其他數(shù)據(jù)庫(kù)系統(tǒng)。

DB-Engines.com排名前100的數(shù)據(jù)庫(kù)

DB-Engines.com是數(shù)據(jù)庫(kù)領(lǐng)域的權(quán)威排行榜，它保留了所有數(shù)據(jù)庫(kù)的流行指數(shù)，使用一種算法進(jìn)行加權(quán)，監(jiān)測(cè)諸如網(wǎng)站上的提及次數(shù)和谷歌的搜索趨勢(shì)，Stack Overflow上的討論或推特中的評(píng)論，工作職位要求的技術(shù)技能，以及在LinkedIn個(gè)人資料中提到這些技術(shù)的數(shù)量。

截至2022年5月，DB-Engines.com上排名前100的數(shù)據(jù)庫(kù)

雖然DB-Engines收集了數(shù)百個(gè)不同的數(shù)據(jù)庫(kù)(截至2022年5月共有394個(gè))。但是本文我們縮小范圍，只觀察前100名數(shù)據(jù)庫(kù)。在很大程度上，反映了市場(chǎng)現(xiàn)狀。

關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)(RDBMS)，傳統(tǒng)的SQL系統(tǒng)，仍然是最大的類別，占列表的47%。

另外，列表中有25%是NoSQL系統(tǒng)，涵蓋了許多不同類型的數(shù)據(jù)庫(kù)，像MongoDB文檔數(shù)據(jù)庫(kù)、Redis鍵值系統(tǒng)、ScyllaDB寬列數(shù)據(jù)庫(kù)，以及Neo4j圖數(shù)據(jù)庫(kù)。

還有11%的數(shù)據(jù)庫(kù)被列為多模型數(shù)據(jù)庫(kù)，包括在同一系統(tǒng)中支持SQL和NoSQL的混合數(shù)據(jù)庫(kù)，如微軟的Cosmos DB或ArangoDB，或者支持多種NoSQL數(shù)據(jù)模型的數(shù)據(jù)庫(kù)，如DynamoDB，它將自己列為NoSQL鍵值系統(tǒng)和文檔存儲(chǔ)。

最后，還有一些是由各種特殊用途的數(shù)據(jù)庫(kù)組成，從搜索引擎到時(shí)間序列數(shù)據(jù)庫(kù)，以及其他不容易歸入簡(jiǎn)單的“SQL與NoSQL”區(qū)域的數(shù)據(jù)庫(kù)。

但是所有這些數(shù)據(jù)庫(kù)都是分布式數(shù)據(jù)庫(kù)嗎?這個(gè)詞到底是什么意思?

分布式數(shù)據(jù)庫(kù)的定義

2016年12月14日，ISO/IEC發(fā)布了最新版本的數(shù)據(jù)庫(kù)語(yǔ)言SQL標(biāo)準(zhǔn)(ISO/IEC9075:2016)。隨著時(shí)間的推移，如何構(gòu)建與SQL兼容的分布式RDBMS系統(tǒng)一直在發(fā)展。分布式SQL，如PostgreSQL或CockroachDB NewSQL系統(tǒng)。

相反，沒(méi)有ANSI或ISO或IETF或W3C定義什么是NoSQL數(shù)據(jù)庫(kù)。每種數(shù)據(jù)庫(kù)都使用自己的專有查詢語(yǔ)言，比如用于寬列NoSQL數(shù)據(jù)庫(kù)的Cassandra查詢語(yǔ)言(CQL)，用于圖形數(shù)據(jù)庫(kù)的Gremlin/Tinkerpop查詢方法。

然而，它們并沒(méi)有定義數(shù)據(jù)如何在這些數(shù)據(jù)庫(kù)中分布，查詢語(yǔ)言也不能解決架構(gòu)問(wèn)題。因此，無(wú)論是SQL還是NoSQL，對(duì)于什么是分布式數(shù)據(jù)庫(kù)，并沒(méi)有標(biāo)準(zhǔn)、協(xié)議或共識(shí)。

因此，我花了一些時(shí)間來(lái)寫(xiě)下我自己的定義。坦率地說(shuō)，這更像是一個(gè)門(mén)外漢的實(shí)用主義觀點(diǎn)，而不是計(jì)算機(jī)科學(xué)教授的見(jiàn)解。

簡(jiǎn)而言之，你必須決定你如何定義集群，以及如何跨集群分配數(shù)據(jù)。接下來(lái)，你必須確定集群中每個(gè)節(jié)點(diǎn)的角色。每個(gè)節(jié)點(diǎn)都是對(duì)等的，還是有些節(jié)點(diǎn)處于更優(yōu)越的領(lǐng)導(dǎo)地位，而其他節(jié)點(diǎn)則是跟隨者。

然后，基于這些角色，你如何處理故障轉(zhuǎn)移？最后，你必須在此基礎(chǔ)上，弄清楚你如何盡可能均勻和容易地復(fù)制和分片數(shù)據(jù)。而這并不試圖做到詳盡無(wú)遺，你可以添加自己的特定條件。

簡(jiǎn)短的清單：感興趣的系統(tǒng)

考慮到這些，我在前100名數(shù)據(jù)庫(kù)中，找到五個(gè)示例，看看它們?cè)跍y(cè)量屬性時(shí)是如何比較的。其中有兩個(gè)SQL系統(tǒng)和三個(gè)NoSQL系統(tǒng)。

Postgres和CockroachDB代表最好的分布式SQL。CockroachDB被稱為 NewSQL，專為分布式數(shù)據(jù)庫(kù)而設(shè)計(jì)。

MongoDB、Redis和ScyllaDB是分布式NoSQL，分別是文檔數(shù)據(jù)庫(kù)，鍵值存儲(chǔ)，寬列數(shù)據(jù)庫(kù)(也被稱為鍵值數(shù)據(jù)庫(kù))。

在大多數(shù)情況下，適用于ScyllaDB的也同樣適用于Apache Cassandra和其他與Cassandra兼容的系統(tǒng)。

假定你擁有專業(yè)的經(jīng)驗(yàn)，而且對(duì)SQL與NoSQL的區(qū)別相對(duì)了解?；旧?，如果需要一個(gè)表JOIN，堅(jiān)持使用SQL和RDBMS。如果你可以將數(shù)據(jù)反規(guī)范化，那么NoSQL可能是一個(gè)很好的選擇。我們不打算討論作為數(shù)據(jù)結(jié)構(gòu)或查詢語(yǔ)言，兩者哪個(gè)“更好”。而是討論作為一個(gè)分布式數(shù)據(jù)庫(kù)，哪個(gè)更好。

多數(shù)據(jù)中心集群

我們的選項(xiàng)在集群方面是如何比較的?現(xiàn)在，它們都能夠進(jìn)行集群，甚至是多數(shù)據(jù)中心操作。但是在PostgreSQL、MongoDB和Redis中，它們最初設(shè)計(jì)于單數(shù)據(jù)中心本地集群，在多數(shù)據(jù)中心設(shè)計(jì)之前就已經(jīng)成為一種架構(gòu)要求。

Postgres首次發(fā)布于1986年，完全早于云計(jì)算的概念。后來(lái)，它允許在其設(shè)計(jì)上，納入這些技術(shù)和能力。

作為NewSQL革命的一部分，CockroachDB從一開(kāi)始就考慮到了全球分布。MongoDB是在公有云誕生之初發(fā)布的，最開(kāi)始設(shè)計(jì)時(shí)考慮到了單數(shù)據(jù)中心集群，但現(xiàn)在已經(jīng)增加了對(duì)許多不同拓?fù)浣Y(jié)構(gòu)的支持。通過(guò)MongoDB Atlas，可以輕松部署到多個(gè)地區(qū)。

Redis，由于其低延遲的設(shè)計(jì)，通常被部署在單個(gè)數(shù)據(jù)中心，但它具有允許多數(shù)據(jù)中心部署的企業(yè)特性。ScyllaDB，像Cassandra一樣，從一開(kāi)始就考慮到了多數(shù)據(jù)中心的部署。

集群管理

如何進(jìn)行復(fù)制和分片，取決于數(shù)據(jù)庫(kù)架構(gòu)的分層或同質(zhì)化程度。

例如，在MongoDB中，有一個(gè)主服務(wù)器，其余的是主服務(wù)器的副本。副本是只讀的，你只能對(duì)這個(gè)數(shù)據(jù)庫(kù)的主副本進(jìn)行寫(xiě)操作，不能直接更新。相反，你寫(xiě)到主數(shù)據(jù)庫(kù)，它就會(huì)更新副本。所以，節(jié)點(diǎn)是異質(zhì)的，而不是同質(zhì)的。

這有助于在讀取繁重的工作負(fù)載中分配流量，但在混合或?qū)懭牍ぷ髫?fù)載中，對(duì)你沒(méi)有一點(diǎn)好處，主服務(wù)器可能會(huì)成為一個(gè)瓶頸。

同樣，如果主服務(wù)器發(fā)生故障會(huì)怎樣?你將不得不完全停止寫(xiě)操作，直到集群選出一個(gè)新的主服務(wù)器，并將寫(xiě)操作分流到它上面。

相反，如果ScyllaDB或Cassandra，或任何其他無(wú)active-active的系統(tǒng)，客戶可以從任何節(jié)點(diǎn)讀取或?qū)懭?。沒(méi)有單一的故障點(diǎn)，節(jié)點(diǎn)的同質(zhì)化程度要高得多。

而且每個(gè)節(jié)點(diǎn)都可以更新集群中的任何數(shù)據(jù)副本。因此，如果你有三個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都會(huì)根據(jù)其他兩個(gè)節(jié)點(diǎn)的任何寫(xiě)入進(jìn)行更新。

active-active在計(jì)算方面本身就比較困難，但是一旦解決了服務(wù)器保持彼此同步的問(wèn)題，就會(huì)得到一個(gè)可以更好地平衡混合或?qū)懭氪罅抗ぷ髫?fù)載的系統(tǒng)，因?yàn)槊總€(gè)節(jié)點(diǎn)都可以提供讀取或?qū)懭敕?wù)。

那么，我們的各種例子在主復(fù)本或active-active對(duì)等方面是如何疊加的?

CockroachDB和ScyllaDB，以及Cassandra一開(kāi)始就考慮了active-active的主動(dòng)式設(shè)計(jì)。在Postgres中，有一些可選的方法可以做到這一點(diǎn)，但它不是內(nèi)置的。

此外，MongoDB沒(méi)有正式支持active-active，但是已經(jīng)有一些人在嘗試如何做到這一點(diǎn)了。

對(duì)于Redis來(lái)說(shuō)，active-active模型在Redis企業(yè)中可以通過(guò)無(wú)沖突復(fù)制數(shù)據(jù)類型(CRDTs)實(shí)現(xiàn)。Postgres、MongoDB和Redis都默認(rèn)使用主副本數(shù)據(jù)分布模型。

復(fù)制

分布式系統(tǒng)設(shè)計(jì)也會(huì)影響如何跨部署到不同機(jī)架或數(shù)據(jù)中心之間分配數(shù)據(jù)。例如，給定一個(gè)主副本系統(tǒng)，只具有主的數(shù)據(jù)中心可以為任何寫(xiě)入工作負(fù)載服務(wù)，其他數(shù)據(jù)中心只能作為只讀副本。

在一個(gè)支持多數(shù)據(jù)中心集群的點(diǎn)對(duì)點(diǎn)系統(tǒng)中，整個(gè)集群中的每個(gè)節(jié)點(diǎn)都可以接受讀或?qū)懖僮鳌?/p>

通過(guò)ScyllaDB，你可以決定每個(gè)站點(diǎn)有相同或甚至不同的復(fù)制因素。這里我展示了在一個(gè)數(shù)據(jù)中心的三個(gè)副本，在另一個(gè)數(shù)據(jù)中心有兩個(gè)副本的可能性。

操作可以有不同級(jí)別的一致性。你可能在三個(gè)節(jié)點(diǎn)的數(shù)據(jù)中心進(jìn)行本地?cái)?shù)據(jù)的讀或?qū)懀枰氯我粩?shù)據(jù)中心的節(jié)點(diǎn)才能成功執(zhí)行操作。可調(diào)整的一致性，結(jié)合多數(shù)據(jù)中心的拓?fù)涓兄?，為工作?fù)載提供更多的靈活性。

拓?fù)涓兄?/h4>

本地集群是分布式數(shù)據(jù)庫(kù)開(kāi)始的方式，允許多個(gè)系統(tǒng)共享負(fù)載。如果想讓數(shù)據(jù)庫(kù)在多個(gè)節(jié)點(diǎn)上進(jìn)行分片，或者通過(guò)確保相同的數(shù)據(jù)在多個(gè)節(jié)點(diǎn)上可用來(lái)實(shí)現(xiàn)高可用性，那么這一點(diǎn)非常重要。

如果所有節(jié)點(diǎn)都安裝在同一個(gè)機(jī)架上，一旦這個(gè)機(jī)架發(fā)生故障，就會(huì)很棘手。因此，添加拓?fù)涓兄?，以便你可以感知同一?shù)據(jù)中心內(nèi)的機(jī)架。確保將數(shù)據(jù)分散在數(shù)據(jù)中心的多個(gè)機(jī)架上，從而最大限度地減少電源或連接丟失到一個(gè)或另一個(gè)機(jī)架的中斷。

有些數(shù)據(jù)庫(kù)做的很好，允許在不同的數(shù)據(jù)中心運(yùn)行數(shù)據(jù)庫(kù)的多個(gè)副本，并使用某種跨集群更新機(jī)制。每個(gè)數(shù)據(jù)庫(kù)都是自主運(yùn)行的，它們的同步機(jī)制可以是單向的，一個(gè)數(shù)據(jù)中心更新一個(gè)下游的副本，也可以是雙向的或多向的。

這種地理分布可以通過(guò)允許更靠近用戶的連接，來(lái)減少延遲?？缈捎眯詤^(qū)域或地區(qū)的數(shù)據(jù)庫(kù)，還可以確保單個(gè)數(shù)據(jù)中心災(zāi)難不會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的部分或全部丟失。

去年我們的一個(gè)客戶就發(fā)生了這種情況，但由于他們部署在三個(gè)不同的數(shù)據(jù)中心，所以數(shù)據(jù)損失為零。

跨集群更新最初是在批量級(jí)別上實(shí)現(xiàn)的。確保你的數(shù)據(jù)中心每天至少有一次同步。這并沒(méi)有持續(xù)多久，后面人們開(kāi)始確保更活躍的事務(wù)級(jí)更新。

如果你在運(yùn)行強(qiáng)一致性數(shù)據(jù)庫(kù)，就會(huì)受到基于光速的實(shí)時(shí)傳播延遲的限制。因此，實(shí)現(xiàn)最終一致性是為了允許每個(gè)操作更新使用多數(shù)據(jù)中心，同時(shí)考慮到在短期內(nèi)，要使所有數(shù)據(jù)中心的數(shù)據(jù)保持一致可能需要時(shí)間。

那么，在拓?fù)涓兄矫?，它是如何疊加的?

所以，CockroachDB和ScyllaDB也是內(nèi)置的。

從2015年開(kāi)始，拓?fù)涓兄渤蔀镸ongoDB的一部分，他們?cè)谶@方面有著多年的經(jīng)驗(yàn)。

Postgres和Redis最初被設(shè)計(jì)為單數(shù)據(jù)中心解決方案，因此處理多數(shù)據(jù)中心的延遲對(duì)兩者來(lái)說(shuō)并非易事?，F(xiàn)在，你可以添加拓?fù)涓兄拖裉砑觓ctive-active系統(tǒng)功能一樣，但它并不是開(kāi)箱即用的。

讓我們回顧一下所討論的內(nèi)容，分別查看這些數(shù)據(jù)庫(kù)的屬性。

PostgreSQL

PostgreSQL是世界上最流行的的開(kāi)源數(shù)據(jù)庫(kù)之一，它以可靠性和穩(wěn)定性而著稱,在處理復(fù)雜SQL方面也表現(xiàn)出了絕對(duì)的優(yōu)勢(shì)。然而，Postgres仍在研究其跨集群和多數(shù)據(jù)中心的集群。

由于SQL基于強(qiáng)一致性事務(wù)模式，所以它不能很好地跨地域跨集群。在所有相關(guān)的數(shù)據(jù)中心之間，每個(gè)查詢都將由于長(zhǎng)時(shí)間的延遲而暫停。

此外，Postgres依靠的是主副本模型。集群中的一個(gè)節(jié)點(diǎn)是領(lǐng)導(dǎo)者，而其他節(jié)點(diǎn)是副本。雖然有負(fù)載平衡器或active-active插件，但這些也超出了基本的服務(wù)范圍。

最后，Postgres的分片在大多數(shù)情況下仍然是手動(dòng)的，盡管他們?cè)陂_(kāi)發(fā)自動(dòng)分片方面取得了進(jìn)展，但這也超出了基本產(chǎn)品的范圍。

CockroachDB

CockroachDB聲稱自己是“NewSQL”，一個(gè)專為分發(fā)而設(shè)計(jì)的SQL數(shù)據(jù)庫(kù)。它可以水平擴(kuò)展，在磁盤(pán)、機(jī)器、機(jī)架，甚至數(shù)據(jù)中心故障時(shí)都能生存下來(lái)，做到延遲最小，無(wú)需手動(dòng)干預(yù)。

值得一提的是，CockroachDB使用Postgres線協(xié)議，并大量借鑒了Postgres開(kāi)創(chuàng)的許多概念，而且并不局限于Postgres的架構(gòu)。

多數(shù)據(jù)中心集群和點(diǎn)對(duì)點(diǎn)的拓?fù)浣Y(jié)構(gòu)從一開(kāi)始就被內(nèi)置。自動(dòng)分片和數(shù)據(jù)復(fù)制也是如此。它還內(nèi)置了數(shù)據(jù)中心感知功能，而且還可以添加機(jī)架感知功能。

對(duì)CockroachDB來(lái)說(shuō)，它要求所有的事務(wù)都有很強(qiáng)的一致性，你可以把它看作是一個(gè)優(yōu)點(diǎn)或缺點(diǎn)。既沒(méi)有最終一致性的靈活性，也沒(méi)有可調(diào)的一致性。這將降低吞吐量，并在任何跨數(shù)據(jù)中心部署中要求較高的基線延遲。

MongoDB

MongoDB是NoSQL領(lǐng)域的領(lǐng)導(dǎo)者。隨著它的發(fā)展，大量的分布式數(shù)據(jù)庫(kù)功能被添加?，F(xiàn)如今，MongoDB能夠支持多數(shù)據(jù)中心集群。在大多數(shù)情況下，它仍然遵循主副本模式，也有辦法使其成為對(duì)等的active-active。

Redis

接下來(lái)是Redis，一個(gè)旨在作為內(nèi)存緩存或數(shù)據(jù)存儲(chǔ)的鍵值存儲(chǔ)。Redis的數(shù)據(jù)全部在內(nèi)存里，如果突然宕機(jī)，數(shù)據(jù)就會(huì)全部丟失，因此必須有一種機(jī)制來(lái)保證Redis的數(shù)據(jù)不會(huì)因?yàn)楣收隙鴣G失，這種機(jī)制就是Redis的持久化機(jī)制。

雖然持久化保存數(shù)據(jù)，但如果數(shù)據(jù)集不適合放在RAM中，它就會(huì)遭受巨大的性能損失。

正因?yàn)槿绱?，它在設(shè)計(jì)時(shí)考慮到了本地集群。如果你無(wú)法承受5毫秒的等待時(shí)間來(lái)從SSD上獲取數(shù)據(jù)，您可能更無(wú)法等待145毫秒來(lái)完成從舊金山到倫敦的網(wǎng)絡(luò)往返時(shí)間。然而，有一些企業(yè)特性允許多數(shù)據(jù)中心的Redis集群。

Redis在大多數(shù)情況下是以主副本模式運(yùn)行的。這適用于大量讀取的緩存服務(wù)器。但這意味著，主節(jié)點(diǎn)是數(shù)據(jù)需要首先寫(xiě)入的地方，然后將這些數(shù)據(jù)分散到副本，以幫助平衡其緩存負(fù)載。

有一個(gè)企業(yè)功能，允許對(duì)等的active-active集群。Redis可以自動(dòng)分片和復(fù)制數(shù)據(jù)，但它的拓?fù)涓兄獌H限于作為企業(yè)功能的機(jī)架感知。

ScyllaDB

ScyllaDB是按照Apache Cassandra中的分布式數(shù)據(jù)庫(kù)模型設(shè)計(jì)的。因此，它默認(rèn)是多數(shù)據(jù)中心集群。它可以自動(dòng)分片，并且每個(gè)操作都有可調(diào)整的一致性，如果你想要更強(qiáng)的一致性，它甚至還支持輕量級(jí)事務(wù)來(lái)提供寫(xiě)入的線性化。

就拓?fù)涓兄?，ScyllaDB支持機(jī)架感知和數(shù)據(jù)中心意識(shí)，甚至支持標(biāo)記感知和分片感知，不僅知道數(shù)據(jù)存儲(chǔ)在哪個(gè)節(jié)點(diǎn)上，甚至可以知道與該數(shù)據(jù)關(guān)聯(lián)的CPU。

結(jié)論

雖然對(duì)于什么是分布式數(shù)據(jù)庫(kù)，還沒(méi)有一個(gè)行業(yè)標(biāo)準(zhǔn)，但是我們可以看到，許多領(lǐng)先的SQL和NoSQL數(shù)據(jù)庫(kù)，都在某種程度上支持一組核心功能或?qū)傩浴Ｆ渲杏行┕δ苁莾?nèi)置的，有些被認(rèn)為是增值包或第三方選項(xiàng)。

在本文分析的五個(gè)典型分布式數(shù)據(jù)庫(kù)系統(tǒng)中，CockroachDB為SQL數(shù)據(jù)庫(kù)提供了最全面的功能和特性，ScyllaDB為NoSQL系統(tǒng)提供了最全面的功能。

該分析應(yīng)被視為某個(gè)時(shí)間段的調(diào)查。鑒于下一個(gè)技術(shù)周期的需求，每一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)都在不斷發(fā)展，這個(gè)行業(yè)并沒(méi)有停滯不前。

對(duì)用戶來(lái)說(shuō)，分布式數(shù)據(jù)庫(kù)每年都在進(jìn)步，變得更加靈活、性能更強(qiáng)、更具彈性和可擴(kuò)展性。