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

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

為了避免Raft高延遲侄榴，我們實(shí)施了領(lǐng)導(dǎo)者的租賃機(jī)制雹锣，這將允許我們無需往返實(shí)現(xiàn)領(lǐng)導(dǎo)者服務(wù)，同時(shí)保留了Raft的線性化特性癞蚕。此外蕊爵，我們使用單調(diào)時(shí)鐘而不是實(shí)時(shí)時(shí)鐘，以容忍時(shí)鐘偏差桦山。

五攒射、我們可以構(gòu)建軟件定義的原子鐘嗎？

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

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

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

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

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

六次泽、重寫或重用PostgreSQL查詢層穿仪？???????

最后但同樣重要的是，我們需要決定是否重寫或重用PostgreSQL查詢層意荤。

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

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

我們的最終決定

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

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

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

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á)式匹配等挺庞。
• CASE 條款
• 加入，特別是 LEFT JOIN
• ORDER BY
• 內(nèi)建等 pg_table_is_visible()

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

結(jié)論

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

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