前些天我發(fā)了一篇解讀信通所分布式數(shù)據(jù)庫發(fā)展報(bào)告內(nèi)容的文章，有些朋友對(duì)我把Aurora、AlloyDB、PolarDB等也歸類于分布式數(shù)據(jù)庫感到有些不解。實(shí)際上這是信通所在報(bào)告里的歸類，和國際上的常見歸類方法也是一致的。通過認(rèn)真研究其架構(gòu)特點(diǎn)，我們也可以發(fā)現(xiàn)，實(shí)際上這些數(shù)據(jù)庫產(chǎn)品（或者嚴(yán)格說是數(shù)據(jù)庫服務(wù)產(chǎn)品）對(duì)傳統(tǒng)集中式數(shù)據(jù)庫進(jìn)行了解耦和負(fù)載下載處理，與我們傳統(tǒng)意義上的集中式數(shù)據(jù)庫讀寫分離已經(jīng)是完全不同的了，只是從我們的使用習(xí)慣上感受到好像這個(gè)數(shù)據(jù)庫和我們使用的集中式數(shù)據(jù)庫并無不同。

今天我就以谷歌的AlloyDB為例，分析一下此類數(shù)據(jù)庫的一些技術(shù)特點(diǎn)。今年4月的GOOGLE I/O上，AlloyDB應(yīng)該是一個(gè)十分亮的亮點(diǎn)。從谷歌官網(wǎng)上也可以看出對(duì)AlloyDB的一些自信。

以僅僅谷歌可以提供的方式來使用PostgreSQL,是不是夠狂，把亞馬遜的Aurora放哪去了？把那么多PG生態(tài)的分布式數(shù)據(jù)庫都放在什么位置？實(shí)際上上圖已經(jīng)點(diǎn)出了Alloy DB的成功要點(diǎn)，PostgreSQL數(shù)據(jù)庫+云原生架構(gòu)+驚人優(yōu)秀的工程團(tuán)隊(duì)+AI/ML的基因是成就AlloyDB的四個(gè)關(guān)鍵。根據(jù)谷歌發(fā)布的性能，AlloyDB比原生態(tài)PG在OLTP場景上處理性能高出4倍，而對(duì)于OLAP場景，則是100倍。雖然目前還沒有正式的測試結(jié)果，業(yè)內(nèi)普遍認(rèn)為，在OLTP場景上，AlloyDB比Aurora在處理性能上高2倍以上，而在OLAP場景上，則呈現(xiàn)秒殺的局面。

AlloyDB是如何做到這一點(diǎn)的呢？我們的數(shù)據(jù)庫廠商是不是也可以充分學(xué)習(xí)AlloyDB的經(jīng)驗(yàn)，來進(jìn)一步優(yōu)化我們的數(shù)據(jù)庫產(chǎn)品呢？實(shí)際上，AlloyDB也是全面學(xué)習(xí)了亞馬遜的Aurora的“日志就是數(shù)據(jù)庫服務(wù)”的理念而研發(fā)出來的數(shù)據(jù)庫服務(wù)產(chǎn)品，并結(jié)合自身的優(yōu)勢，發(fā)揚(yáng)光大了Aurora的優(yōu)勢，切實(shí)彌補(bǔ)了Aurora的不足。在官網(wǎng)上說，AlloyDB 結(jié)合了 Google 的橫向擴(kuò)展計(jì)算和存儲(chǔ)、行業(yè)領(lǐng)先的可用性、安全性和 AI/ML 支持的管理與完全 PostgreSQL 兼容性（基于PG 14.4），以及性能、可擴(kuò)展性、可管理性。如果用更為通俗的語言來表達(dá)就是，AlloyDB保持了與PostgreSQL的全兼容，并在橫向擴(kuò)展和計(jì)算能力以及可用性、安全性上充分利用了谷歌云的分布式架構(gòu)。并且充分利用了AI/ML技術(shù)。

亞馬遜的Auora出現(xiàn)于2014年，是一個(gè)真正云原生的數(shù)據(jù)庫產(chǎn)品，雖然其數(shù)據(jù)庫服務(wù)的RDBMS本身是基于MySQL和PostgreSQL這兩個(gè)開源數(shù)據(jù)庫，不過其充分利用了云存儲(chǔ)的多副本復(fù)制與多ZONE高可用特性，創(chuàng)建了一種非對(duì)稱讀寫分離的新型數(shù)據(jù)庫服務(wù)架構(gòu)。而8年后，作為后來者，AlloyDB在此基礎(chǔ)上又有了很多值得我們學(xué)習(xí)的創(chuàng)新。

我們先來看看AlloyDB的一些技術(shù)特性。從高可用上，AlloyDB實(shí)現(xiàn)了連帶維護(hù)工作耗時(shí)在內(nèi)的真正的99.99%的高可用，并通過準(zhǔn)確的自動(dòng)檢測，AlloyDB可以在絕大多數(shù)故障場景中，在幾分鐘內(nèi)實(shí)現(xiàn)故障恢復(fù)，并且與數(shù)據(jù)庫的負(fù)載和大小無關(guān)。通過內(nèi)存中的列模式緩沖，AlloyDB可以支持較為復(fù)雜的HTAP場景。

AlloyDB的特性來源于其獨(dú)特的架構(gòu)設(shè)計(jì)。我們先來看看AlloyDB的一張讀寫流的示意圖。

AlloyDB在一個(gè)區(qū)域里可以劃分為多個(gè)安全區(qū)，其主庫和只讀從庫分別位于不同的AZ。這個(gè)架構(gòu)和Aurora十分類似，都是使用了共享塊存儲(chǔ)。不過如果仔細(xì)看這張圖，我們會(huì)發(fā)現(xiàn)一些在Aurora或者一些國產(chǎn)的模仿者中不同的地方。AlloyDB 存儲(chǔ)層是一個(gè)分布式系統(tǒng)，由三個(gè)主要部分組成： 1）低延遲的區(qū)域日志存儲(chǔ)服務(wù)，用于非?？焖俚念A(yù)寫日志 (WAL) 寫入；2）處理這些 WAL 記錄并生成“物化”數(shù)據(jù)庫塊 的日志處理服務(wù)（LPS)；3）容錯(cuò)、分片的區(qū)域塊存儲(chǔ)，即使在區(qū)域存儲(chǔ)發(fā)生故障的情況下也能確保持久性。

我們重點(diǎn)來看LPS，這是AlloyDB與Aurora不同的主要地方，AlloyDB對(duì)LPS做了很好的優(yōu)化，主實(shí)例中的WAL數(shù)據(jù)以流的方式實(shí)時(shí)傳輸給其他的副本，用于更新副本的SHARED BUFFERS，這種更新方式比起副本完全依靠WAL重演來還原最新數(shù)據(jù)要高效的多，也可以避免因?yàn)橹鲗?shí)例中出現(xiàn)大量修改而引起副本重演延時(shí)過大的問題。

另外這種架構(gòu)下，BGWRITER或者類似openGauss的PAGEWRITER沒有了，被LPS完全替代了。主實(shí)例只需要將WAL數(shù)據(jù)流寫入低延時(shí)的日志存儲(chǔ)就可以了，數(shù)據(jù)文件的變更是完全依靠日志文件重演來實(shí)現(xiàn)的。也就是說一旦數(shù)據(jù)庫創(chuàng)建，今后所有的PAGE的變化都基于WAL STREAM，因此困擾PG數(shù)據(jù)庫十多年的FULL PAGE WRITE的問題也就消失了，這種結(jié)構(gòu)下，永遠(yuǎn)不需要FULL PAGE WRITE和CHECKPOINT了。

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

而對(duì)于讀操作來說，由于LPS的存在，因此讀操作上可能會(huì)有一定的性能損失，因?yàn)樽x路徑的路徑比傳統(tǒng)的方式長了一些。所有的計(jì)算與存儲(chǔ)分離架構(gòu)的數(shù)據(jù)庫都會(huì)或多或少的加長讀取的路徑，因此都會(huì)對(duì)讀取性能有些影響。因此AlloyDB采用了十分激進(jìn)的緩沖策略，希望通過更高的緩沖命中率來抵消這方面的缺點(diǎn)。實(shí)際上在激進(jìn)的緩沖策略方面，谷歌全系列產(chǎn)品都如此，谷歌在這方面積累了豐富的經(jīng)驗(yàn)，因此AlloyDB 也不例外。除了數(shù)據(jù)庫緩沖區(qū)之外，AlloyDB 還在計(jì)算實(shí)例中添加了“超高速緩存”。這個(gè)緩沖區(qū)十分類似Oracle的FlashCache，其目的是為了讓被DB CACHE淘汰的數(shù)據(jù)能夠在此二次緩沖，避免通過較長的讀取路徑去讀取。因此Ultra-fast Cache被設(shè)計(jì)為本地的，這一點(diǎn)也和Oracle的FlashCache類似。Ultra-fast Cache讓更多的數(shù)據(jù)能夠從本實(shí)例的緩沖中獲得，因此大大減輕由于SHARED BUFFERS沒有命中數(shù)據(jù)塊導(dǎo)致的IO路徑上的各種損失。同樣值得注意的是,DB CACHE中未命中的數(shù)據(jù)塊是從LPS獲取的，而不是從塊存儲(chǔ)服務(wù)獲取的。LPS除了具備處理WAL的能力外，還支持PostgreSQL的buffer cache接口。它這樣做是為了緩存來自塊存儲(chǔ)服務(wù)的數(shù)據(jù)塊，并將它們提供給主實(shí)例和副本實(shí)例。因此，LPS有效地成為架構(gòu)中的另一個(gè)緩存層。

作為一個(gè)存算分離的分布式數(shù)據(jù)庫系統(tǒng)，AlloyDB在設(shè)計(jì)上的創(chuàng)新還沒有到頭，因?yàn)長PS統(tǒng)一了持久化服務(wù)，將傳統(tǒng)PG的bgwriter/walwriter的功能以及前臺(tái)進(jìn)程統(tǒng)一為一個(gè)服務(wù)，同時(shí)截?cái)嗔薭ackend訪問PAGE的讀取路徑，因此真正徹底的把計(jì)算層和存儲(chǔ)層分離了。

在這個(gè)架構(gòu)里，LPS變成了整個(gè)數(shù)據(jù)庫的性能要點(diǎn)，因?yàn)?LPS 既需要持續(xù)應(yīng)用 WAL 記錄，又需要服務(wù)來自主實(shí)例和多個(gè)副本實(shí)例的讀取請(qǐng)求。為了解決這個(gè)問題，數(shù)據(jù)庫持久層被水平劃分為稱為分片的塊組。分片和 LPS 資源都可以水平且獨(dú)立地?cái)U(kuò)展。每個(gè)分片會(huì)被固定分配給一個(gè) LPS，但每個(gè) LPS 可以處理多個(gè)分片。分片到 LPS 的映射是動(dòng)態(tài)的，允許存儲(chǔ)層通過擴(kuò)展 LPS 資源的數(shù)量和重新分配分片來彈性地進(jìn)行擴(kuò)充。這不僅允許存儲(chǔ)層擴(kuò)展吞吐量，還可以避免熱點(diǎn)。

谷歌官方網(wǎng)站給出了兩個(gè)參考場景：第一個(gè)例子是當(dāng)整體系統(tǒng)負(fù)載增加，幾乎所有分片都收到比以前更多的請(qǐng)求。在這種情況下，存儲(chǔ)層可以增加 LPS 實(shí)例的數(shù)量，例如將它們加倍。然后，新創(chuàng)建的日志處理服務(wù)器實(shí)例通過接管它們的一些分片來卸載現(xiàn)有實(shí)例。由于這種分片重新分配不涉及任何數(shù)據(jù)復(fù)制或其他昂貴的操作，因此它非?？焖偾覍?duì)數(shù)據(jù)庫層不可見。

另一個(gè)例子是一小部分分片突然在系統(tǒng)中變得非常熱的時(shí)候，同樣存儲(chǔ)層可以動(dòng)態(tài)做出反應(yīng)——在最極端的情況下，如果發(fā)現(xiàn)有某個(gè)分片過熱，訪問流量不均勻，則可以通過將某個(gè)負(fù)載超高的分片分配給專門處理分片負(fù)載的專用 LPS 實(shí)例來避免過熱的分片的性能不足。因此，通過重新分片和 LPS 彈性，即使在工作負(fù)載高峰的情況下，系統(tǒng)也可以提供高性能和吞吐量，并且在工作負(fù)載再次減少時(shí)也可以減少其資源占用。對(duì)于數(shù)據(jù)庫層和最終用戶，這種動(dòng)態(tài)調(diào)整大小和存儲(chǔ)層彈性是完全自動(dòng)的，不需要用戶操作。這是AI4DB能力的極好的應(yīng)用。

AlloyDB的存儲(chǔ)層是采用多副本的，其三副本數(shù)據(jù)位于不同的ZONE，并且確保每個(gè)區(qū)域都有自己的完整數(shù)據(jù)庫狀態(tài)副本，因此數(shù)據(jù)庫層的塊查找操作不需要跨越區(qū)域邊界。此外，存儲(chǔ)層在所有區(qū)域中持續(xù)應(yīng)用 WAL 記錄，數(shù)據(jù)庫層為其請(qǐng)求的每個(gè)塊提供目標(biāo)版本 LSN，因此在讀取操作期間無需讀取仲裁，在享受分布式橫向擴(kuò)展的同時(shí)也享受到了類似于集中式數(shù)據(jù)庫的便捷性。

總而言之，AlloyDB通過解耦數(shù)據(jù)庫的計(jì)算層和存儲(chǔ)層來獲得較強(qiáng)的橫向擴(kuò)展能力，并通過LPS將許多數(shù)據(jù)庫讀寫操作卸載到存儲(chǔ)層。即使在存儲(chǔ)層，完全分解的架構(gòu)也允許它作為一個(gè)彈性的分布式集群工作，可以動(dòng)態(tài)適應(yīng)不斷變化的工作負(fù)載，增加容錯(cuò)能力，提高可用性，并啟用具有成本效益的讀取池，以線性擴(kuò)展讀取吞吐量。卸載還有效提升了主實(shí)例的寫入吞吐量，因?yàn)樗梢酝耆珜Ｗ⒂诓樵兲幚聿⒕S護(hù)任務(wù)委托給存儲(chǔ)層。而這種能力來自于AlloyDB 的智能、數(shù)據(jù)庫感知存儲(chǔ)層在AI技術(shù)上的使用。我想這些設(shè)計(jì)思想都會(huì)給我們的國產(chǎn)數(shù)據(jù)庫廠商帶來一種新的數(shù)據(jù)庫設(shè)計(jì)思路，分布式數(shù)據(jù)庫在總體架構(gòu)上不一定非要完全學(xué)習(xí)Oracle，也可以脫離Oracle的技術(shù)框架，充分利用開源代碼來走一條新路。

從今天的描述，可能有些朋友已經(jīng)發(fā)現(xiàn)了AlloyDB與傳統(tǒng)的集中式數(shù)據(jù)庫的不同了。目前我們的國產(chǎn)數(shù)據(jù)庫也在學(xué)習(xí)Aurora，不過學(xué)的還不夠徹底，最主要的是存算解耦還不夠徹底，負(fù)載無法從計(jì)算層更好的卸載到存儲(chǔ)層，這和我們還沒有能力徹底改造計(jì)算存儲(chǔ)兩層之間的接口，使之變成可橫向擴(kuò)展的服務(wù)有關(guān)。