幾款分散式資料庫的對比

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

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系統提供了最全面的功能。

該分析應被視為某個時間段的調查。鑑於下一個技術週期的需求，每一個資料庫系統都在不斷髮展，這個行業並沒有停滯不前。

對使用者來說，分散式資料庫每年都在進步，變得更加靈活、效能更強、更具彈性和可擴充套件性。