大約10年前，我加入了Amazon Web Services，在那裡我第一次看到了在分布式系統中進行權衡的重要性。在大學裡，我已經了解了一致性和可用性之間的權衡（CAP定理），但實際上，頻譜要比這深得多。任何設計決策都可能涉及延遲，並發性，可伸縮性，耐用性，可維護性，功能性，操作簡便性以及系統其他方面之間的權衡，而這些權衡會對應用程式的功能和用戶體驗產生有意義的影響，並且即使是業務本身的有效性。

也許在權衡需求最明顯的分布式系統中最具挑戰性的問題是構建分布式資料庫。當應用程式開始需要可以在許多伺服器上擴展的資料庫時，資料庫開發人員開始做出極端的權衡。為了在許多節點上實現可伸縮性，分布式鍵值存儲（NoSQL）拋棄了傳統關係數據庫管理系統（RDBMS）提供的豐富功能集，包括SQL，聯接，外鍵和ACID保證。由於每個人都想要可伸縮性，因此RDBMS消失只是時間問題，對嗎？實際上，關係數據庫繼續主導著資料庫領域。這就是為什麼：

在分布式系統（或任何系統）中進行權衡時，要考慮的最重要方面是開發成本。

資料庫軟體所做出的權衡將對應用程式的開發成本產生重大影響。在高級應用程式中處理需要可用性，可靠性和性能的數據是一個固有地需要解決的問題。成功解決每個小問題所需的工時數量可能很大。幸運的是，資料庫可以解決許多這些子問題，但是資料庫開發人員也面臨成本問題。實際上，要使資料庫足以滿足大多數應用程式的功能，保證和性能，就需要數十年的時間。那就是建立關係數據庫如PostgreSQL和MySQL的地方。

在Citus Data，我們從不同角度解決了資料庫可伸縮性的需求。我和我的團隊在過去的幾年中花費了很多時間將已建立的RDBMS轉換為分布式資料庫，而又不會失去其強大功能或從基礎項目中分叉。通過這樣做，我們發現RDBMS是構建分布式資料庫的理想基礎。

通過在RDBMS之上構建來降低應用程式開發成本

使RDBMS對開發應用程式（尤其是開源RDBMS，尤其是雲RDBMS）如此吸引人的原因在於，您可以有效地利用數十年來對RDBMS進行的工程投資，並利用這些RDBMS功能。您的應用，降低了開發成本。

RDBMS為您提供：

1. 圍繞數據完整性和持久性的有意義的保證
2. 極大的靈活性來操縱和查詢數據
3. 最先進的算法和數據結構，可在各種工作負載下獲得高性能。

這些功能幾乎對任何非平凡的應用都很重要，但是要花很長時間才能開發。另一方面，某些應用程式的工作量對於單台計算機來說太過苛刻，因此需要水平可伸縮性。

許多新的分布式資料庫正在開發中，並且正在分布式鍵值存儲（「 NewSQL」）之上實現RDBMS功能，例如SQL。儘管這些較新的資料庫可以使用多台計算機的資源，但是在SQL支持，查詢性能，並發性，索引，外鍵，事務，存儲過程等方面，它們仍遠未建立在關係數據庫系統上。您遇到許多要在應用程式中解決的複雜問題。

許多大型網際網路公司採用的替代方法是RDBMS的手動，應用程式層分片（通常是PostgreSQL或MySQL）。手動分片意味著有許多RDBMS節點，並且應用程式會根據某種條件（例如，用戶ID）決定連接到哪個節點。應用程式本身負責如何處理數據放置，架構更改，查詢多個節點，複製表等，因此，如果執行手動分片，最終將在應用程式中實現自己的分布式資料庫，這可能甚至更多。昂貴。

幸運的是，有一種方法可以解決開發成本難題。

PostgreSQL已有數十年的發展歷史，其令人難以置信的重點是代碼質量，模塊化和可擴展性。這種可擴展性提供了一個獨特的機會：無需分叉就可以將PostgreSQL轉換為分布式資料庫。這就是我們構建Citus的方式。

Citus：成為世界上最先進的分布式資料庫

大約5年前，當我加入一家名為Citus Data的初創公司時，我為在競爭激烈的市場中建立高級分布式資料庫而無任何現有基礎架構，品牌知名度，進入市場，資本或大量工程師的挑戰感到沮喪 。 僅開發成本就似乎是無法克服的。 但是，就像應用程式開發人員利用PostgreSQL來構建複雜的應用程式一樣，我們利用PostgreSQL來構建……分布式PostgreSQL。

我們創建了Citus，這是開源的PostgreSQL擴展，而不是從頭開始創建分布式資料庫，它以提供水平擴展的方式透明地分發表和查詢，但是應用程式開發人員需要具備所有PostgreSQL功能才能成功。

通過使用在計劃查詢時Postgres調用的內部掛鉤，我們能夠將分布式表的概念添加到Postgres。

分布式表的分片存儲在具有所有現有功能的常規PostgreSQL節點中，Citus發送常規SQL命令以查詢分片，然後合併結果。 我們還添加了參考表的概念，該參考表可在所有節點上複製，因此可以通過任何列與分布式表連接。 通過進一步增加對分布式事務，查詢路由，分布式子查詢和CTE，序列，更新等的支持，我們達到了最先進的PostgreSQL功能可以使用的規模，但現在已經可以大規模使用。

Citus相對來說還很年輕，但是已經建立在PostgreSQL之上，已經成為世界上最先進的分布式資料庫之一。與PostgreSQL的完整功能集相比，這令人毛骨悚然，還有許多工作要做，Citus現在提供的功能及其擴展方式使其在分布式資料庫環境中具有很大的獨特性。許多當前的Citus用戶最初使用Postgres中的許多高級功能在單節點PostgreSQL伺服器上建立業務，然後僅用幾周的開發工作就遷移到Citus，以將其資料庫模式轉換為分布式表和引用表。對於任何其他資料庫，從單節點資料庫到分布式資料庫的這種遷移可能要花費數月甚至數年的時間。

使用Citus將Postgres功能轉變為超級強大

像PostgreSQL這樣的RDBMS具有幾乎無限的功能和成熟的SQL引擎，可讓您以多種方式查詢數據。當然，這些功能只有在速度很快時才對應用程式有用。幸運的是，PostgreSQL很快，並且通過諸如實時查詢編譯之類的新功能不斷提高，但是當您擁有大量數據或流量以至於一台機器速度太慢時，那些強大的功能就不再那麼有用了……除非您可以結合許多計算機的計算能力。這就是功能成為超級大國的地方。

通過採用PostgreSQL功能並進行擴展，Citus具有許多超級功能，這些功能使用戶可以將資料庫擴展到任意大小，同時保持高性能及其所有功能。

• 查詢路由意味著獲取查詢（作為查詢的一部分），並讓存儲相關分片的RDBMS節點處理查詢，而不是收集或重新整理中間結果，當查詢通過分發列進行過濾和合併時，這是可能的。查詢路由使Citus能夠為多租戶（SaaS）應用程式大規模支持底層PostgreSQL伺服器的所有SQL功能，這些應用程式通常按租戶ID進行過濾。就分布式查詢計劃時間和網絡流量而言，此方法具有最小的開銷，可實現高並發性和低延遲。
• 與順序執行相比，跨分布式表中所有分片的並行，分布式SELECT允許您在短時間內查詢大量數據，這意味著您可以構建具有一致響應時間的應用程式，即使您的數據和客戶數量通過擴展資料庫來增長。 Citus查詢計劃程序將從多個分片中讀取數據的SELECT查詢轉換為一個或多個類似於map-reduce的步驟，其中並行查詢每個分片（map），然後合併或重新組合結果（reduce）。對於線性比例尺，大多數工作應在映射步驟中完成，對於聯接或按分布列分組的查詢通常是這種情況。
• 聯接是SQL的重要組成部分，其原因有兩個：1）它們提供了極大的靈活性，可以以不同的方式查詢數據，從而避免了應用程式中複雜的數據處理邏輯； 2）它們使您的數據表示更加緊湊。 。如果沒有聯接，則需要在每一行中存儲大量冗餘信息，這將大大增加存儲，掃描表或將其保留在內存中所需的硬體數量。通過聯接，您可以存儲緊湊的不透明ID並進行高級過濾，而不必讀取所有數據。
• 參考表看起來像其他任何表一樣，但是它們在群集中的所有節點之間透明地複製。在典型的星型模式中，所有維表都將是參考表，而事實表則是分布式表。然後，事實表可以與任何列上的任何維表結合（並行！），而無需通過網絡移動任何數據。在多租戶應用程式中，參考表可用於保存在租戶之間共享的數據。
• 子查詢下推是並行，分布式SELECT，查詢路由和聯接之間的結合。可以通過子查詢下推在單個回合中並行化包含高級子查詢樹的所有分片中的查詢（例如子查詢之間的聯接），只要它們可以聯接分布列上的所有分布式表（而引用表可以在任何列上聯接）。這將啟用非常高級的分析查詢，該查詢仍具有線性可伸縮性。 Citus可以利用PostgreSQL計劃程序已經對所有查詢進行的轉換來識別可下推的子查詢，並為所有剩餘的子查詢生成單獨的計劃。這允許有效地分布所有子查詢和CTE。
• 索引就像桌子的腿。沒有它們，要從桌子上拿東西會很費力，而且實際上不是桌子。 PostgreSQL特別提供了非常強大的索引功能，例如部分索引，表達式索引，GIN，GiST，BRIN和覆蓋索引。這使查詢（包括聯接！）即使在大規模時也能保持快速。值得記住的是，索引查找通常比掃描數據的一千個內核快。 Citus通過索引各個分片來支持所有PostgreSQL索引類型。像Heap和Microsoft這樣的高級用戶尤其喜歡使用部分索引來處理針對許多不同事件類型的各種查詢。
• 分布式事務允許您一次或根本不進行一組更改，這大大提高了應用程式的可靠性。 Citus可以使用類似於查詢下推的方法將事務委派給PostgreSQL節點，並繼承其ACID屬性。對於跨碎片的交易，Citus使用PostgreSQL的內置2PC機制，並添加了一個分布式死鎖檢測器，該檢測器使用PostgreSQL內部函數從所有節點獲取鎖表。
• 並行，分布式DML允許以相對較少的時間和事務方式轉換和維護大量數據。分布式DML的常見應用是INSERT…SELECT命令，該命令將原始數據表中的行聚合到匯總表中。通過在所有可用內核上並行執行INSERT…SELECT，資料庫將始終足夠快以聚集傳入的事件，而應用程式（例如儀錶板）將查詢緊湊的，高索引的匯總表。另一個例子是Citus用戶，他吸收了260億行不良數據，並使用分布式更新對其進行了修復，平均每秒修改了70萬行。
• 批量加載是分析大量數據的應用程式的一項基本功能。即使在單個節點上，PostgreSQL的COPY命令也可以每秒向表追加數十萬行，這已經超過了大多數分布式資料庫基準測試。 Citus可以散出COPY流，以在許多PostgreSQL伺服器上並行添加和索引許多行，這可以擴展到每秒數百萬行。
• 存儲過程和函數（包括觸發器）在資料庫內部提供了一個編程環境，用於實現單個SQL查詢無法捕獲的業務邏輯。當您需要一組操作來進行事務處理而無需在應用程式伺服器和資料庫之間來回移動時，對資料庫進行編程的功能特別有用。使用存儲過程可以簡化您的應用程式，並使資料庫更高效，因為您可以避免在進行網絡往返時保持事務打開。儘管它可能會給資料庫帶來更多的負載，但是在資料庫擴展時，這將不再是一個大問題。

儘管大多數這些功能對於開發需要擴展的複雜應用程式來說似乎都是必不可少的，但並不是所有分布式資料庫都支持它們。下面我們根據公開提供的文檔對一些流行的分布式資料庫進行比較。

讓我們的力量結​​合起來……

與在分布式資料庫中擁有超級功能相比，更重要的是能夠組合資料庫超級功能來解決複雜的用例。

由於支持查詢路由，參考表，索引，分布式事務和存儲過程，因此即使最先進的多租戶OLTP應用程式（例如Copper）也可以使用Citus擴展到單個PostgreSQL節點之外，而不會在應用程式中做出任何犧牲。

如果將子查詢下推與並行的分布式DML結合使用，則可以在資料庫內部轉換大量數據。一個常見的示例是使用INSERT…SELECT構建匯總表，該表可以並行化以適應任何類型的數據量。結合通過COPY，索引，聯接和分區進行的批量加載，您將擁有一個非常適合時間序列數據和實時分析應用程式（如Algolia儀錶板）的資料庫。

正如Microsoft的Min Wei在談到Microsoft如何使用Citus和PostgreSQL分析Windows數據時指出的那樣：Citus使您能夠使用分布式OLTP解決大規模OLAP問題。

GoodOldSQL

Citus與其他分布式資料庫有些不同，後者通常是從頭開始開發的。 Citus沒有引入PostgreSQL中尚未提供的任何功能。 Citus資料庫以滿足需要擴展的用例的方式擴展了現有功能。重要的是，大多數PostgreSQL功能已經針對各種用例進行了數十年的開發和測試，而當今用例的功能要求最終並沒有太大不同；主要是數據的規模和大小不同。因此，在構建現代應用程式時，基於世界上最先進的開源RDBMS（PostgreSQL！）構建的分布式資料庫（如Citus）可以成為您的武器庫中最強大的工具。

原文：https://www.citusdata.com/blog/2018/11/30/why-rdbms-is-the-future-of-distributed-databases/

本文：http://jiagoushi.pro/node/929

討論：請加入知識星球或者微信圈子【首席架構師圈】