從AlloyDb的架構能學到些什麼

前些天我發了一篇解讀信通所分散式資料庫發展報告內容的文章，有些朋友對我把Aurora、AlloyDB、PolarDB等也歸類於分散式資料庫感到有些不解。實際上這是信通所在報告裡的歸類，和國際上的常見歸類方法也是一致的。透過認真研究其架構特點，我們也可以發現，實際上這些資料庫產品(或者嚴格說是資料庫服務產品)對傳統集中式資料庫進行了解耦和負載下載處理，與我們傳統意義上的集中式資料庫讀寫分離已經是完全不同的了，只是從我們的使用習慣上感受到好像這個資料庫和我們使用的集中式資料庫並無不同。

今天我就以谷歌的AlloyDB為例，分析一下此類資料庫的一些技術特點。今年4月的GOOGLE I/O上，AlloyDB應該是一個十分亮的亮點。從谷歌官網上也可以看出對AlloyDB的一些自信。

以僅僅谷歌可以提供的方式來使用PostgreSQL,是不是夠狂，把亞馬遜的Aurora放哪去了?把那麼多PG生態的分散式資料庫都放在什麼位置?實際上上圖已經點出了Alloy DB的成功要點，PostgreSQL資料庫+雲原生架構+驚人優秀的工程團隊+AI/ML的基因是成就AlloyDB的四個關鍵。根據谷歌釋出的效能，AlloyDB比原生態PG在OLTP場景上處理效能高出4倍，而對於OLAP場景，則是100倍。雖然目前還沒有正式的測試結果，業內普遍認為，在OLTP場景上，AlloyDB比Aurora在處理效能上高2倍以上，而在OLAP場景上，則呈現秒殺的局面。

AlloyDB是如何做到這一點的呢?我們的資料庫廠商是不是也可以充分學習AlloyDB的經驗，來進一步最佳化我們的資料庫產品呢?實際上，AlloyDB也是全面學習了亞馬遜的Aurora的“日誌就是資料庫服務”的理念而研發出來的資料庫服務產品，並結合自身的優勢，發揚光大了Aurora的優勢，切實彌補了Aurora的不足。在官網上說，AlloyDB 結合了 Google 的橫向擴充套件計算和儲存、行業領先的可用性、安全性和 AI/ML 支援的管理與完全 PostgreSQL 相容性(基於PG 14.4)，以及效能、可擴充套件性、可管理性。如果用更為通俗的語言來表達就是，AlloyDB保持了與PostgreSQL的全相容，並在橫向擴充套件和計算能力以及可用性、安全性上充分利用了谷歌雲的分散式架構。並且充分利用了AI/ML技術。

亞馬遜的Auora出現於2014年，是一個真正雲原生的資料庫產品，雖然其資料庫服務的RDBMS本身是基於MySQL和PostgreSQL這兩個開源資料庫，不過其充分利用了雲端儲存的多副本複製與多ZONE高可用特性，建立了一種非對稱讀寫分離的新型資料庫服務架構。而8年後，作為後來者，AlloyDB在此基礎上又有了很多值得我們學習的創新。

我們先來看看AlloyDB的一些技術特性。從高可用上，AlloyDB實現了連帶維護工作耗時在內的真正的99.99%的高可用，並透過準確的自動檢測，AlloyDB可以在絕大多數故障場景中，在幾分鐘內實現故障恢復，並且與資料庫的負載和大小無關。透過記憶體中的列模式緩衝，AlloyDB可以支援較為複雜的HTAP場景。

AlloyDB的特性來源於其獨特的架構設計。我們先來看看AlloyDB的一張讀寫流的示意圖。

AlloyDB在一個區域裡可以劃分為多個安全區，其主庫和只讀從庫分別位於不同的AZ。這個架構和Aurora十分類似，都是使用了共享塊儲存。不過如果仔細看這張圖，我們會發現一些在Aurora或者一些國產的模仿者中不同的地方。AlloyDB 儲存層是一個分散式系統，由三個主要部分組成： 1)低延遲的區域日誌儲存服務，用於非常快速的預寫日誌 (WAL) 寫入;2)處理這些 WAL 記錄並生成“物化”資料庫塊 的日誌處理服務(LPS);3)容錯、分片的區域塊儲存，即使在區域儲存發生故障的情況下也能確保永續性。

我們重點來看LPS，這是AlloyDB與Aurora不同的主要地方，AlloyDB對LPS做了很好的最佳化，主例項中的WAL資料以流的方式實時傳輸給其他的副本，用於更新副本的SHARED BUFFERS，這種更新方式比起副本完全依靠WAL重演來還原最新資料要高效的多，也可以避免因為主例項中出現大量修改而引起副本重演延時過大的問題。

另外這種架構下，BGWRITER或者類似openGauss的PAGEWRITER沒有了，被LPS完全替代了。主例項只需要將WAL資料流寫入低延時的日誌儲存就可以了，資料檔案的變更是完全依靠日誌檔案重演來實現的。也就是說一旦資料庫建立，今後所有的PAGE的變化都基於WAL STREAM，因此困擾PG資料庫十多年的FULL PAGE WRITE的問題也就消失了，這種結構下，永遠不需要FULL PAGE WRITE和CHECKPOINT了。

上面是AlloyDB的寫入流程，我們可以看到，只需要把WAL寫入LOG STORE就可以了，沒有BGWRITER，不需要考慮CHECKPOINT的最佳化，沒有FULL PAGE WRITE，一切都由LPS搞定。

而對於讀操作來說，由於LPS的存在，因此讀操作上可能會有一定的效能損失，因為讀路徑的路徑比傳統的方式長了一些。所有的計算與儲存分離架構的資料庫都會或多或少的加長讀取的路徑，因此都會對讀取效能有些影響。因此AlloyDB採用了十分激進的緩衝策略，希望透過更高的緩衝命中率來抵消這方面的缺點。實際上在激進的緩衝策略方面，谷歌全系列產品都如此，谷歌在這方面積累了豐富的經驗，因此AlloyDB 也不例外。除了資料庫緩衝區之外，AlloyDB 還在計算例項中新增了“超快取記憶體”。這個緩衝區十分類似Oracle的FlashCache，其目的是為了讓被DB CACHE淘汰的資料能夠在此二次緩衝，避免透過較長的讀取路徑去讀取。因此Ultra-fast Cache被設計為本地的，這一點也和Oracle的FlashCache類似。Ultra-fast Cache讓更多的資料能夠從本例項的緩衝中獲得，因此大大減輕由於SHARED BUFFERS沒有命中資料塊導致的IO路徑上的各種損失。同樣值得注意的是,DB CACHE中未命中的資料塊是從LPS獲取的，而不是從塊儲存服務獲取的。LPS除了具備處理WAL的能力外，還支援PostgreSQL的buffer cache介面。它這樣做是為了快取來自塊儲存服務的資料塊，並將它們提供給主例項和副本例項。因此，LPS有效地成為架構中的另一個快取層。

作為一個存算分離的分散式資料庫系統，AlloyDB在設計上的創新還沒有到頭，因為LPS統一了持久化服務，將傳統PG的bgwriter/walwriter的功能以及前臺程式統一為一個服務，同時截斷了backend訪問PAGE的讀取路徑，因此真正徹底的把計算層和儲存層分離了。

在這個架構裡，LPS變成了整個資料庫的效能要點，因為 LPS 既需要持續應用 WAL 記錄，又需要服務來自主例項和多個副本例項的讀取請求。為了解決這個問題，資料庫持久層被水平劃分為稱為分片的塊組。分片和 LPS 資源都可以水平且獨立地擴充套件。每個分片會被固定分配給一個 LPS，但每個 LPS 可以處理多個分片。分片到 LPS 的對映是動態的，允許儲存層透過擴充套件 LPS 資源的數量和重新分配分片來彈性地進行擴充。這不僅允許儲存層擴充套件吞吐量，還可以避免熱點。

谷歌官方網站給出了兩個參考場景：第一個例子是當整體系統負載增加，幾乎所有分片都收到比以前更多的請求。在這種情況下，儲存層可以增加 LPS 例項的數量，例如將它們加倍。然後，新建立的日誌處理伺服器例項透過接管它們的一些分片來解除安裝現有例項。由於這種分片重新分配不涉及任何資料複製或其他昂貴的操作，因此它非常快速且對資料庫層不可見。

另一個例子是一小部分分片突然在系統中變得非常熱的時候，同樣儲存層可以動態做出反應——在最極端的情況下，如果發現有某個分片過熱，訪問流量不均勻，則可以透過將某個負載超高的分片分配給專門處理分片負載的專用 LPS 例項來避免過熱的分片的效能不足。因此，透過重新分片和 LPS 彈性，即使在工作負載高峰的情況下，系統也可以提供高效能和吞吐量，並且在工作負載再次減少時也可以減少其資源佔用。對於資料庫層和終端使用者，這種動態調整大小和儲存層彈性是完全自動的，不需要使用者操作。這是AI4DB能力的極好的應用。

AlloyDB的儲存層是採用多副本的，其三副本資料位於不同的ZONE，並且確保每個區域都有自己的完整資料庫狀態副本，因此資料庫層的塊查詢操作不需要跨越區域邊界。此外，儲存層在所有區域中持續應用 WAL 記錄，資料庫層為其請求的每個塊提供目標版本 LSN，因此在讀取操作期間無需讀取仲裁，在享受分散式橫向擴充套件的同時也享受到了類似於集中式資料庫的便捷性。

總而言之，AlloyDB透過解耦資料庫的計算層和儲存層來獲得較強的橫向擴充套件能力，並透過LPS將許多資料庫讀寫操作解除安裝到儲存層。即使在儲存層，完全分解的架構也允許它作為一個彈性的分散式叢集工作，可以動態適應不斷變化的工作負載，增加容錯能力，提高可用性，並啟用具有成本效益的讀取池，以線性擴充套件讀取吞吐量。解除安裝還有效提升了主例項的寫入吞吐量，因為它可以完全專注於查詢處理並將維護任務委託給儲存層。而這種能力來自於AlloyDB 的智慧、資料庫感知儲存層在AI技術上的使用。我想這些設計思想都會給我們的國產資料庫廠商帶來一種新的資料庫設計思路，分散式資料庫在總體架構上不一定非要完全學習Oracle，也可以脫離Oracle的技術框架，充分利用開原始碼來走一條新路。

從今天的描述，可能有些朋友已經發現了AlloyDB與傳統的集中式資料庫的不同了。目前我們的國產資料庫也在學習Aurora，不過學的還不夠徹底，最主要的是存算解耦還不夠徹底，負載無法從計算層更好的解除安裝到儲存層，這和我們還沒有能力徹底改造計算儲存兩層之間的介面，使之變成可橫向擴充套件的服務有關。

AlloyDB的技術創新不止於此，今天我只是介紹了傳統資料庫範疇的創新，而對於HTAP能力，AlloyDB依然創意滿滿，今天時間有限，我明天再給大家介紹。