前些天我發了一篇解讀信通所分布式數據庫發展報告內容的文章，有些朋友對我把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，不過學的還不夠徹底，最主要的是存算解耦還不夠徹底，負載無法從計算層更好的卸載到存儲層，這和我們還沒有能力徹底改造計算存儲兩層之間的接口，使之變成可橫向擴展的服務有關。