過去十年見證了分布式數據庫的崛起。不僅通過本地集群來實現負載均衡，并提供高可用性，還具有數據中心內的機架感知等屬性。專為云而設計的分布式數據庫，可以跨越可用性區域，通過編排技術，支持公有云、私有云、混合云部署。近年來，市面上出現了大量專為分布式數據庫部署而設計的新數據庫系統，以及在初始設計中添加了分布式架構組件的其他數據庫系統。

DB-Engines.com排名前100的數據庫

DB-Engines.com是數據庫領域的權威排行榜，它保留了所有數據庫的流行指數，使用一種算法進行加權，監測諸如網站上的提及次數和谷歌的搜索趨勢，Stack Overflow上的討論或推特中的評論，工作職位要求的技術技能，以及在LinkedIn個人資料中提到這些技術的數量。

截至2022年5月，DB-Engines.com上排名前100的數據庫

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

關系型數據庫管理系統(RDBMS)，傳統的SQL系統，仍然是最大的類別，占列表的47%。

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

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

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

但是所有這些數據庫都是分布式數據庫嗎?這個詞到底是什么意思?

分布式數據庫的定義

2016年12月14日，ISO/IEC發布了最新版本的數據庫語言SQL標準(ISO/IEC9075:2016)。隨著時間的推移，如何構建與SQL兼容的分布式RDBMS系統一直在發展。分布式SQL，如PostgreSQL或CockroachDB NewSQL系統。

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

然而，它們并沒有定義數據如何在這些數據庫中分布，查詢語言也不能解決架構問題。因此，無論是SQL還是NoSQL，對于什么是分布式數據庫，并沒有標準、協議或共識。

因此，我花了一些時間來寫下我自己的定義。坦率地說，這更像是一個門外漢的實用主義觀點，而不是計算機科學教授的見解。

簡而言之，你必須決定你如何定義集群，以及如何跨集群分配數據。接下來，你必須確定集群中每個節點的角色。每個節點都是對等的，還是有些節點處于更優越的領導地位，而其他節點則是跟隨者。

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

簡短的清單：感興趣的系統

考慮到這些，我在前100名數據庫中，找到五個示例，看看它們在測量屬性時是如何比較的。其中有兩個SQL系統和三個NoSQL系統。

Postgres和CockroachDB代表最好的分布式SQL。CockroachDB被稱為 NewSQL，專為分布式數據庫而設計。

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

在大多數情況下，適用于ScyllaDB的也同樣適用于Apache Cassandra和其他與Cassandra兼容的系統。

假定你擁有專業的經驗，而且對SQL與NoSQL的區別相對了解。基本上，如果需要一個表JOIN，堅持使用SQL和RDBMS。如果你可以將數據反規范化，那么NoSQL可能是一個很好的選擇。我們不打算討論作為數據結構或查詢語言，兩者哪個“更好”。而是討論作為一個分布式數據庫，哪個更好。

多數據中心集群

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

Postgres首次發布于1986年，完全早于云計算的概念。后來，它允許在其設計上，納入這些技術和能力。

作為NewSQL革命的一部分，CockroachDB從一開始就考慮到了全球分布。MongoDB是在公有云誕生之初發布的，最開始設計時考慮到了單數據中心集群，但現在已經增加了對許多不同拓撲結構的支持。通過MongoDB Atlas，可以輕松部署到多個地區。

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

集群管理

如何進行復制和分片，取決于數據庫架構的分層或同質化程度。

例如，在MongoDB中，有一個主服務器，其余的是主服務器的副本。副本是只讀的，你只能對這個數據庫的主副本進行寫操作，不能直接更新。相反，你寫到主數據庫，它就會更新副本。所以，節點是異質的，而不是同質的。

這有助于在讀取繁重的工作負載中分配流量，但在混合或寫入工作負載中，對你沒有一點好處，主服務器可能會成為一個瓶頸。

同樣，如果主服務器發生故障會怎樣?你將不得不完全停止寫操作，直到集群選出一個新的主服務器，并將寫操作分流到它上面。

相反，如果ScyllaDB或Cassandra，或任何其他無active-active的系統，客戶可以從任何節點讀取或寫入。沒有單一的故障點，節點的同質化程度要高得多。

而且每個節點都可以更新集群中的任何數據副本。因此，如果你有三個節點，每個節點都會根據其他兩個節點的任何寫入進行更新。

active-active在計算方面本身就比較困難，但是一旦解決了服務器保持彼此同步的問題，就會得到一個可以更好地平衡混合或寫入大量工作負載的系統，因為每個節點都可以提供讀取或寫入服務。

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

CockroachDB和ScyllaDB，以及Cassandra一開始就考慮了active-active的主動式設計。在Postgres中，有一些可選的方法可以做到這一點，但它不是內置的。

此外，MongoDB沒有正式支持active-active，但是已經有一些人在嘗試如何做到這一點了。

對于Redis來說，active-active模型在Redis企業中可以通過無沖突復制數據類型(CRDTs)實現。Postgres、MongoDB和Redis都默認使用主副本數據分布模型。

復制

分布式系統設計也會影響如何跨部署到不同機架或數據中心之間分配數據。例如，給定一個主副本系統，只具有主的數據中心可以為任何寫入工作負載服務，其他數據中心只能作為只讀副本。

在一個支持多數據中心集群的點對點系統中，整個集群中的每個節點都可以接受讀或寫操作。

通過ScyllaDB，你可以決定每個站點有相同或甚至不同的復制因素。這里我展示了在一個數據中心的三個副本，在另一個數據中心有兩個副本的可能性。

操作可以有不同級別的一致性。你可能在三個節點的數據中心進行本地數據的讀或寫，需要更新任一數據中心的節點才能成功執行操作。可調整的一致性，結合多數據中心的拓撲感知，為工作負載提供更多的靈活性。

拓撲感知

本地集群是分布式數據庫開始的方式，允許多個系統共享負載。如果想讓數據庫在多個節點上進行分片，或者通過確保相同的數據在多個節點上可用來實現高可用性，那么這一點非常重要。

如果所有節點都安裝在同一個機架上，一旦這個機架發生故障，就會很棘手。因此，添加拓撲感知，以便你可以感知同一數據中心內的機架。確保將數據分散在數據中心的多個機架上，從而最大限度地減少電源或連接丟失到一個或另一個機架的中斷。

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

這種地理分布可以通過允許更靠近用戶的連接，來減少延遲。跨可用性區域或地區的數據庫，還可以確保單個數據中心災難不會導致數據庫的部分或全部丟失。

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

跨集群更新最初是在批量級別上實現的。確保你的數據中心每天至少有一次同步。這并沒有持續多久，后面人們開始確保更活躍的事務級更新。

如果你在運行強一致性數據庫，就會受到基于光速的實時傳播延遲的限制。因此，實現最終一致性是為了允許每個操作更新使用多數據中心，同時考慮到在短期內，要使所有數據中心的數據保持一致可能需要時間。

那么，在拓撲感知方面，它是如何疊加的?

所以，CockroachDB和ScyllaDB也是內置的。

從2015年開始，拓撲感知也成為MongoDB的一部分，他們在這方面有著多年的經驗。

Postgres和Redis最初被設計為單數據中心解決方案，因此處理多數據中心的延遲對兩者來說并非易事。現在，你可以添加拓撲感知，就像添加active-active系統功能一樣，但它并不是開箱即用的。

讓我們回顧一下所討論的內容，分別查看這些數據庫的屬性。

PostgreSQL

PostgreSQL是世界上最流行的的開源數據庫之一，它以可靠性和穩定性而著稱,在處理復雜SQL方面也表現出了絕對的優勢。然而，Postgres仍在研究其跨集群和多數據中心的集群。

由于SQL基于強一致性事務模式，所以它不能很好地跨地域跨集群。在所有相關的數據中心之間，每個查詢都將由于長時間的延遲而暫停。

此外，Postgres依靠的是主副本模型。集群中的一個節點是領導者，而其他節點是副本。雖然有負載平衡器或active-active插件，但這些也超出了基本的服務范圍。

最后，Postgres的分片在大多數情況下仍然是手動的，盡管他們在開發自動分片方面取得了進展，但這也超出了基本產品的范圍。

CockroachDB

CockroachDB聲稱自己是“NewSQL”，一個專為分發而設計的SQL數據庫。它可以水平擴展，在磁盤、機器、機架，甚至數據中心故障時都能生存下來，做到延遲最小，無需手動干預。

值得一提的是，CockroachDB使用Postgres線協議，并大量借鑒了Postgres開創的許多概念，而且并不局限于Postgres的架構。

多數據中心集群和點對點的拓撲結構從一開始就被內置。自動分片和數據復制也是如此。它還內置了數據中心感知功能，而且還可以添加機架感知功能。

對CockroachDB來說，它要求所有的事務都有很強的一致性，你可以把它看作是一個優點或缺點。既沒有最終一致性的靈活性，也沒有可調的一致性。這將降低吞吐量，并在任何跨數據中心部署中要求較高的基線延遲。

MongoDB

MongoDB是NoSQL領域的領導者。隨著它的發展，大量的分布式數據庫功能被添加。現如今，MongoDB能夠支持多數據中心集群。在大多數情況下，它仍然遵循主副本模式，也有辦法使其成為對等的active-active。

Redis

接下來是Redis，一個旨在作為內存緩存或數據存儲的鍵值存儲。Redis的數據全部在內存里，如果突然宕機，數據就會全部丟失，因此必須有一種機制來保證Redis的數據不會因為故障而丟失，這種機制就是Redis的持久化機制。

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

正因為如此，它在設計時考慮到了本地集群。如果你無法承受5毫秒的等待時間來從SSD上獲取數據，您可能更無法等待145毫秒來完成從舊金山到倫敦的網絡往返時間。然而，有一些企業特性允許多數據中心的Redis集群。

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

有一個企業功能，允許對等的active-active集群。Redis可以自動分片和復制數據，但它的拓撲感知僅限于作為企業功能的機架感知。

ScyllaDB

ScyllaDB是按照Apache Cassandra中的分布式數據庫模型設計的。因此，它默認是多數據中心集群。它可以自動分片，并且每個操作都有可調整的一致性，如果你想要更強的一致性，它甚至還支持輕量級事務來提供寫入的線性化。

就拓撲感知而言，ScyllaDB支持機架感知和數據中心意識，甚至支持標記感知和分片感知，不僅知道數據存儲在哪個節點上，甚至可以知道與該數據關聯的CPU。

結論

雖然對于什么是分布式數據庫，還沒有一個行業標準，但是我們可以看到，許多領先的SQL和NoSQL數據庫，都在某種程度上支持一組核心功能或屬性。其中有些功能是內置的，有些被認為是增值包或第三方選項。

在本文分析的五個典型分布式數據庫系統中，CockroachDB為SQL數據庫提供了最全面的功能和特性，ScyllaDB為NoSQL系統提供了最全面的功能。

該分析應被視為某個時間段的調查。鑒于下一個技術周期的需求，每一個數據庫系統都在不斷發展，這個行業并沒有停滯不前。

對用戶來說，分布式數據庫每年都在進步，變得更加靈活、性能更強、更具彈性和可擴展性。