我們?cè)诮衲?月跨越了YugaByte DB三年開(kāi)發(fā)階段，到目前為止，這是一段驚心動(dòng)魄的旅程，但并非沒(méi)有公平的技術(shù)挑戰(zhàn)。有時(shí)我們不得不回到繪圖板，甚至篩選學(xué)術(shù)研究，以找到比我們手頭的更好的解決方案，在這篇文章中，我們將概述在構(gòu)建開(kāi)源，云原生，高性能分布式SQL數(shù)據(jù)庫(kù)的過(guò)程中我們必須解決的一些最難的架構(gòu)問(wèn)題。

好的，讓我們開(kāi)始探討從最簡(jiǎn)單到***挑戰(zhàn)性的問(wèn)題：

1.架構(gòu)：亞馬遜Aurora還是谷歌Spanner？

我們?cè)缙谧龀龅囊粋€(gè)決定是找到一個(gè)我們可以用作YugaByte DB架構(gòu)靈感的數(shù)據(jù)庫(kù)。我們密切關(guān)注兩個(gè)系統(tǒng)，Amazon Aurora和Google Spanner。

Amazon Aurora是一個(gè)提供高可用性的SQL數(shù)據(jù)庫(kù)。它具有與流行的RDBMS數(shù)據(jù)庫(kù)（如MySQL和PostgreSQL）的兼容性，使其易于入門(mén)并可運(yùn)行各種應(yīng)用程序。Amazon Aurora也是AWS歷史上發(fā)展最快的服務(wù)之一。

Amazon Aurora服務(wù)與MySQL和PostgreSQL兼容，是AWS歷史上發(fā)展最快的服務(wù)。

Amazon Aurora具有可擴(kuò)展的數(shù)據(jù)存儲(chǔ)層，但查詢(xún)層不是這樣。以下是我們發(fā)現(xiàn)的Amazon Aurora的一些關(guān)鍵可擴(kuò)展性限制：

• 寫(xiě)入不是水平可伸縮的。擴(kuò)展寫(xiě)入吞吐量的唯一方法是垂直擴(kuò)展處理所有寫(xiě)入的節(jié)點(diǎn)（稱(chēng)為主節(jié)點(diǎn)）。這種擴(kuò)展方案只是到目前為止，因此數(shù)據(jù)庫(kù)能處理多少寫(xiě)入IOPS存在固有的限制。
• 寫(xiě)入不是全局一致的。許多現(xiàn)代的云原生應(yīng)用程序本質(zhì)上是全局性的，需要跨多個(gè)區(qū)域部署底層數(shù)據(jù)庫(kù)。但是，Aurora僅支持多主機(jī)部署，在發(fā)生沖突時(shí)***一個(gè)寫(xiě)入程序（具有***時(shí)間戳）獲勝。這可能導(dǎo)致不一致。
• 通過(guò)使用犧牲一致性的從屬副本以獲得讀取的伸縮擴(kuò)展。為了擴(kuò)展讀取，應(yīng)用程序需要連接到從屬節(jié)點(diǎn)才能實(shí)現(xiàn)讀取。當(dāng)使用這些從屬節(jié)點(diǎn)實(shí)現(xiàn)讀取時(shí)，應(yīng)用程序需要面對(duì)降級(jí)的一致性語(yǔ)義，以及一個(gè)單獨(dú)的連接端點(diǎn)。這使得應(yīng)用程序架構(gòu)非常復(fù)雜。

另外，Google Spanner是一個(gè)可水平擴(kuò)展的SQL數(shù)據(jù)庫(kù)，專(zhuān)為大規(guī)?？蓴U(kuò)展和地理分布式應(yīng)用程序而構(gòu)建。

Cloud Spanner是唯一為云構(gòu)建的企業(yè)級(jí)、全局分布且高度一致的數(shù)據(jù)庫(kù)服務(wù)，專(zhuān)門(mén)用于將關(guān)系數(shù)據(jù)庫(kù)結(jié)構(gòu)的優(yōu)勢(shì)與非關(guān)系水平擴(kuò)展相結(jié)合。

這意味著Spanner可以無(wú)縫擴(kuò)展讀寫(xiě)，支持需要全局一致性的地理分布式應(yīng)用程序，并在不犧牲正確性的情況下從多個(gè)節(jié)點(diǎn)執(zhí)行讀取。

但是，它放棄了RDBMS數(shù)據(jù)庫(kù)提供給開(kāi)發(fā)人員期望的許多熟悉功能集。例如，Google Spanner文檔中突出顯示了不支持外鍵約束或觸發(fā)器的事實(shí)。

我們決定采用混合方法。

• YugaByte DB的核心存儲(chǔ)架構(gòu)受到Google Spanner的啟發(fā)，該架構(gòu)專(zhuān)為水平可擴(kuò)展性和地理分布式應(yīng)用程序而構(gòu)建。
• YugaByte DB保留了與Amazon Aurora類(lèi)似的PostgreSQL兼容查詢(xún)層，它可以支持豐富的功能集，并支持最廣泛的用例。

2. SQL協(xié)議：PostgreSQL還是MySQL？

我們想要對(duì)廣泛采用的SQL方言進(jìn)行標(biāo)準(zhǔn)化。我們還希望它是開(kāi)源的，并且在數(shù)據(jù)庫(kù)周?chē)鷵碛谐墒斓纳鷳B(tài)系統(tǒng)。權(quán)衡的自然選擇是PostgreSQL和MySQL？

我們之所以選擇PostgreSQL（而不是MySQL），原因如下：

• PostgreSQL有一個(gè)更寬松的許可證，更符合YugaByte DB的開(kāi)源精神。
• 與任何其他SQL數(shù)據(jù)庫(kù)相比，PostgreSQL在過(guò)去幾年中的流行度一直在飆升，這絕對(duì)沒(méi)有受到影響！

在目前排在DB-Engines排名網(wǎng)站前10位的五個(gè)SQL數(shù)據(jù)庫(kù)中，自2014年以來(lái)，只有PostgreSQL的受歡迎程度越來(lái)越高，而其他數(shù)據(jù)庫(kù)則趨于平穩(wěn)或正在失去理智。

此外，對(duì)于許多應(yīng)用程序，PostgreSQL是Oracle的***替代品。組織正在被PostgreSQL所吸引，因?yàn)樗情_(kāi)源的，供應(yīng)商中立（MySQL由Oracle擁有），擁有一個(gè)參與的開(kāi)發(fā)者社區(qū)，一個(gè)繁榮的供應(yīng)商生態(tài)系統(tǒng)，一個(gè)強(qiáng)大的功能集，以及一個(gè)成熟的代碼庫(kù)，一直在戰(zhàn)斗 - 經(jīng)過(guò)20多年的嚴(yán)格使用而堅(jiān)固。

3.分布式事務(wù)：Google Spanner或Percolator？

關(guān)于我們應(yīng)該如何設(shè)計(jì)分布式事務(wù)，我們查看了Google Spanner和Percolator。

總而言之，Google Percolator提供高吞吐量但使用單個(gè)時(shí)間戳。這種方法本質(zhì)上是不可擴(kuò)展的，僅適用于單個(gè)數(shù)據(jù)中心，面向?qū)崟r(shí)分析（稱(chēng)為HTAP）的應(yīng)用程序，而不是OLTP應(yīng)用程序。另一方面，Google Spanner的分散時(shí)間跟蹤方法對(duì)于地理分布式OLTP和單數(shù)據(jù)中心HTAP應(yīng)用程序來(lái)說(shuō)都是一個(gè)很好的解決方案。

Google Spanner是在Google Percolator之后構(gòu)建的，用于替換廣告后端中手動(dòng)分片的MySQL部署，以實(shí)現(xiàn)水平可擴(kuò)展性和地理分布式用例。但是，考慮到其真正的分布式特性以及對(duì)時(shí)鐘偏移跟蹤的需求，Google Spanner的構(gòu)建難度要高一個(gè)數(shù)量級(jí)。

有關(guān)此主題的更多詳細(xì)信息，您可以詳細(xì)了解Percolator與Spanner的權(quán)衡。

我們決定采用Google Spanner方法，因?yàn)樗梢灾С郑?/p>

• 更好的水平可擴(kuò)展性
• 高度可用且性能更佳的多區(qū)域部署。

我們堅(jiān)信，大多數(shù)現(xiàn)代云應(yīng)用都需要上述兩種功能。實(shí)際上，GDPR和總共提供100個(gè)地區(qū)的公共云等合規(guī)性要求已經(jīng)使這成為現(xiàn)實(shí)。

4. Raft是否適用于地理分布式工作負(fù)載？

Raft和Paxos是眾所周知的分布式共識(shí)算法，并且已被正式證明是安全的，Spanner使用Paxos，但是，我們選擇了Raft，因?yàn)椋?/p>

• 對(duì)于開(kāi)發(fā)人員和運(yùn)營(yíng)團(tuán)隊(duì)Raft比Paxos更容易理解。
• 它提供動(dòng)態(tài)更改成員資格的能力，這是至關(guān)重要的（例如：在不影響性能的情況下更改機(jī)器類(lèi)型）。（banq注：Raft與Paxos主要區(qū)別在于Raft候選人可以是任何一個(gè)服務(wù)器節(jié)點(diǎn)，不需要專(zhuān)門(mén)指定候選人，否則這些候選人全部宕機(jī)怎么辦？如同一些TCC分布式事務(wù)中存在事務(wù)協(xié)調(diào)器一樣有單點(diǎn)風(fēng)險(xiǎn)）

然而，為了確保可線性化的讀取，Raft要求接收讀取查詢(xún)的每個(gè)***在實(shí)際提供讀取查詢(xún)之前首先將心跳消息傳播到Raft組中的大多數(shù)節(jié)點(diǎn)。在某些情況下，這可能會(huì)嚴(yán)重降低讀取性能。這種情況的一個(gè)示例是地理分布式部署，其中往返會(huì)顯著增加延遲，并且在諸如臨時(shí)網(wǎng)絡(luò)分區(qū)之類(lèi)的事件的情況下增加失敗查詢(xún)的數(shù)量。

為了避免Raft高延遲，我們實(shí)施了***的租賃機(jī)制，這將允許我們無(wú)需往返實(shí)現(xiàn)***服務(wù)，同時(shí)保留了Raft的線性化特性。此外，我們使用單調(diào)時(shí)鐘而不是實(shí)時(shí)時(shí)鐘，以容忍時(shí)鐘偏差。

5.我們可以構(gòu)建軟件定義的原子鐘嗎？

作為分布式數(shù)據(jù)庫(kù)，YugaByte DB支持跨多個(gè)節(jié)點(diǎn)的多鍵ACID事務(wù)（快照和可序列化隔離級(jí)別），即使存在故障也是如此。這需要一個(gè)可以跨節(jié)點(diǎn)同步時(shí)間的時(shí)鐘。

Google Spanner使用TrueTime，這是一個(gè)具有嚴(yán)格錯(cuò)誤界限的高可用性全局同步時(shí)鐘的示例。但是，許多部署中都沒(méi)有此類(lèi)時(shí)鐘。

物理時(shí)鐘（或掛鐘）不能在節(jié)點(diǎn)之間***同步。因此，他們無(wú)法跨節(jié)點(diǎn)排序事件（建立因果關(guān)系）。除非存在中央時(shí)間戳權(quán)限，否則諸如Lamport時(shí)鐘和向量時(shí)鐘之類(lèi)的邏輯時(shí)鐘不會(huì)跟蹤物理時(shí)間，這成為可擴(kuò)展性瓶頸。

我們的方案: 混合邏輯時(shí)鐘（HLC）通過(guò)將使用NTP粗略同步的物理時(shí)鐘與跟蹤因果關(guān)系的Lamport時(shí)鐘相結(jié)合來(lái)解決該問(wèn)題。

YugaByte DB使用HLC作為高可用性群集寬時(shí)鐘，具有用戶(hù)指定的***時(shí)鐘偏差上限值。HLC值在Raft組中用作關(guān)聯(lián)更新的方式，也用作MVCC讀取點(diǎn)。結(jié)果是符合ACID的分布式數(shù)據(jù)庫(kù)，如Jepsen測(cè)試所示。

6.重寫(xiě)或重用PostgreSQL查詢(xún)層？​​​​​​​

***但同樣重要的是，我們需要決定是否重寫(xiě)或重用PostgreSQL查詢(xún)層。

我們的初步?jīng)Q定

YugaByte數(shù)據(jù)庫(kù)查詢(xún)層在設(shè)計(jì)時(shí)考慮了可擴(kuò)展性。通過(guò)在C ++中重寫(xiě)API服務(wù)器，已經(jīng)在這個(gè)查詢(xún)層框架中構(gòu)建了兩個(gè)API（YCQL和YEDIS），首先重寫(xiě)PostgreSQL API似乎更容易和自然。

我們的最終決定

在我們意識(shí)到這不是一條理想的道路之前，我們沿著這條路走了大約5個(gè)月。與PostgreSQL成熟，完整的數(shù)據(jù)庫(kù)相比，其他API要簡(jiǎn)單得多。然后我們重新完成整個(gè)工作，回到繪圖板并重新開(kāi)始重新使用PostgreSQL的查詢(xún)層代碼。雖然這在開(kāi)始時(shí)很痛苦，但回顧起來(lái)它是一個(gè)更好的策略。

這種方法也有其自身的挑戰(zhàn)。我們的計(jì)劃是首先將PostgreSQL系統(tǒng)表移動(dòng)到DocDB（YugaByte DB的存儲(chǔ)層），最初支持一些數(shù)據(jù)類(lèi)型和一些簡(jiǎn)單查詢(xún)，并隨著時(shí)間的推移添加更多數(shù)據(jù)類(lèi)型和查詢(xún)支持。

不幸的是，這個(gè)計(jì)劃并沒(méi)有完全解決。要從psql執(zhí)行看似簡(jiǎn)單的最終用戶(hù)命令，實(shí)際上需要支持大量SQL功能。例如，\d用于列出所有表的命令在內(nèi)部執(zhí)行以下查詢(xún)：

 c.relname as "Name", 
  CASE c.relkind 
    WHEN 'r' THEN 'table' 
    WHEN 'v' THEN 'view' 
    WHEN 'm' THEN 'materialized view' 
    WHEN 'i' THEN 'index' 
    WHEN 'S' THEN 'sequence' 
    WHEN 's' THEN 'special' 
    WHEN 'f' THEN 'foreign table' 
  END as "Type", 
  pg_catalog.pg_get_userbyid(c.relowner) as "Owner" 
FROM pg_catalog.pg_class c 
     LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace 
WHERE c.relkind IN ('r','') 
  AND n.nspname <> 'pg_catalog' 
  AND n.nspname <> 'information_schema' 
  AND n.nspname !~ '^pg_toast' 
  AND pg_catalog.pg_table_is_visible(c.oid) 
ORDER BY 1,2;  

WHERE支持操作符，例如IN，不等于，正則表達(dá)式匹配等。滿足上述查詢(xún)需要支持以下功能：

• CASE 條款
• 加入，特別是 LEFT JOIN
• ORDER BY 
• 內(nèi)建等 pg_table_is_visible()

顯然，這代表了各種各樣的SQL功能，因此我們必須在創(chuàng)建單個(gè)用戶(hù)表之前使所有這些功能都可用！我們?cè)贕oogle Spanner架構(gòu)上發(fā)布分布式PostgreSQL - 查詢(xún)層突出顯示了查詢(xún)層的詳細(xì)工作方式。

結(jié)論

即使對(duì)于專(zhuān)家用戶(hù)來(lái)說(shuō)，不得不在市場(chǎng)上可用的許多數(shù)據(jù)庫(kù)之間進(jìn)行選擇，一開(kāi)始看起來(lái)似乎勢(shì)不可擋。這是因?yàn)闉榻o定類(lèi)型的應(yīng)用程序選擇數(shù)據(jù)庫(kù)取決于這些數(shù)據(jù)庫(kù)在其體系結(jié)構(gòu)中所做的權(quán)衡。

通過(guò)YugaByte DB，我們以一種新穎的方式組合了一組非常實(shí)用的架構(gòu)決策，以創(chuàng)建一個(gè)獨(dú)特的開(kāi)源分布式SQL數(shù)據(jù)庫(kù)。PostgreSQL強(qiáng)大的SQL功能現(xiàn)在可供您使用，零數(shù)據(jù)丟失，水平寫(xiě)入可擴(kuò)展性，低讀取延遲以及在公共云或Kubernetes中本機(jī)運(yùn)行的能力。