?昨天發(fā)了一篇關于AlloyDB的文章，有朋友給我留言，也有朋友通過微信做了一些交流，實際上AlloyDB到底能不能成功，能獲得多大的成功還是個未知數(shù)。并且因為AlloyDB旨在GCP上提供，不提供云下版本，因此我也沒辦法真實的去體驗AlloyDB，僅僅從發(fā)布會上及會后一些體驗者的實驗報告中獲得一些特性方面的信息。只不過我覺得AlloyDB為云原生數(shù)據(jù)庫提供了一個十分好的樣板，在很多設計上都具有劃時代意義的創(chuàng)新。如谷歌官方所說，AlloyDB關注的是未來及當下數(shù)據(jù)庫用戶的最大的關注點：高可擴展性、高性能、高可用性、易于管理、實時運維可觀測性、AL/ML能力。

如上圖所示，通過Intelligent Database Storage Engine，AlloyDB消除了數(shù)據(jù)庫BLOCK的回寫，只剩下WAL WRITE。計算引擎只需要把WAL寫入低延時日志存儲層，那么事務提交就完成了。數(shù)據(jù)文件的落盤是異步的，通過LPS服務使用WAL來完成。這種設計參考了分布式消息中間件等的設計思路，以往采用此類實現(xiàn)的都是一些簡單的系統(tǒng)，而谷歌把這種設計用到了十分復雜的數(shù)據(jù)庫上。

消除塊寫，是充分利用現(xiàn)代硬件和云平臺的高可擴展性和性能特點的一種設計。通過并行的LPS可以并發(fā)處理大量的WAL寫入和BLOCK落盤，通過低延時的LOG STORE，可以快速的完成WAL落盤，避免引起數(shù)據(jù)庫事務提交的性能問題。這也是AlloyDB不支持跨數(shù)據(jù)中心的主要原因（跨數(shù)據(jù)中心需要通過復制）。昨天和朋友的交流中，也表示了對LOG STORE與計算節(jié)點分離后的性能問題的擔憂，不過想想Oracle的Exadata，計算節(jié)點與存儲節(jié)點之間也存在復雜的IO路徑，只要能夠優(yōu)化好，實際上也是問題不大的。我們的傳統(tǒng)數(shù)據(jù)庫架構，從服務器到存儲系統(tǒng)，也有很長的IO路徑。

昨天大家比較關心的另外一個問題，如果計算引擎不寫B(tài)LOCK了，那么是不是要等LPS完成日志數(shù)據(jù)重演，數(shù)據(jù)才能讀取呢？實際上這個擔心是不必要的，谷歌也意識到了AlloyDB的讀取路徑有點長，因此為了降低OLTP的延時，設計了一種多層緩沖機制的讀取架構。如果LPS還沒有完成某個BLOCK的持久化寫入，那么這個BLOCK相關的數(shù)據(jù)是在LPS BUFFER CACHE里緩存的，可以直接從LPS BUFFER CACHE里命中該數(shù)據(jù)（哪怕寫入完成，如果該BLOCK還沒有老化，那么在BUFFER CACHE中也可能命中），如果在此層命中，則訪問效率會更高，因為LPS所在的設備的IO性能更好。

我覺得還是用昨天那張寫入流程的圖可以更為準確的描述寫入操作。在WAL落盤的同時，WAL STREAM會被同步到只讀節(jié)點，用于更新只讀節(jié)點的BUFFER CACHE（與主節(jié)點的BUFFER CACHE同步）。為什么要這么做呢？對于基于“日志就是數(shù)據(jù)庫”理念設計的讀寫分離共享存儲數(shù)據(jù)庫系統(tǒng)，只讀節(jié)點與主節(jié)點之間并不是完全實時的，因為只有當BLOCK被寫入后，從節(jié)點才能獲取到最新的版本。在主節(jié)點緩沖區(qū)中暫時沒有落盤的數(shù)據(jù)有可能沒有提交就已經(jīng)落盤，也有可能落盤后還沒有提交。因此對從節(jié)點的一致性讀造成了影響。去年的一篇分析PolarDB的架構的文章中，我也提出了這個問題，當時我也提出了可以采用緩沖區(qū)融合或者更為簡化的方案來替代目前PolarDB僅僅依靠日志重演來實現(xiàn)主從同步的方案。

在那篇文章里，我也分析了PolarDB日志重演算法可能引發(fā)的一些讀節(jié)點因為重演延時而導致的讀最新數(shù)據(jù)的阻塞問題。

在那篇文章中，我也談到了目前PolarDB采用的日志重演的方式存在的缺陷以及通過WAL STREAMS直接同步BUFFER CACHE的設想。在這里我就不多說了，大家有興趣可以區(qū)翻閱一下。PolarDB設計了多種結構來避免重演存在的問題，設計也十分精巧，只不過還是沒有脫離BLOCK持久化的慣性，因此每個從節(jié)點都需要獨立的重演日志。AlloyDB在這方面的解決方案更加漂亮，AlloyDB的從節(jié)點不需要重演日志，因為日志重演變成了一個公共服務，不論主節(jié)點還是從節(jié)點，一個集群里只需要一次統(tǒng)一的持久化為目的的重演。

利用WAL STREAMS同步了BUFFER CACHE后，主從節(jié)點之間就沒有任何數(shù)據(jù)延遲了。國內(nèi)現(xiàn)在有些數(shù)據(jù)庫廠商也都在搞類似Aurora的分布式數(shù)據(jù)庫產(chǎn)品，AlloyDB是一個很好的學習榜樣。我不太贊成數(shù)據(jù)庫廠商去通過類似Oracle Cache fusion的方式來實現(xiàn)類似RAC的功能，因為這個太復雜了，DLM/GES/GCS等服務想要做好并不容易。而類似AlloyDB這種實現(xiàn)是很容易的，也能夠滿足絕大多數(shù)用戶的需求。特別是云原生數(shù)據(jù)庫，這種架構比CACHE FUSION為核心的RAC有更好的橫向擴展能力。

昨天很多朋友對AlloyDB如何實現(xiàn)HTAP，實現(xiàn)分析類SQL 100倍的性能提升。也有一些朋友對100倍的性能提升提出了疑問，認為很難實現(xiàn)。AlloyDB的HTAP是通過實例內(nèi)的列引擎實現(xiàn)的。行數(shù)據(jù)在內(nèi)存中生成了列緩沖副本，這個實現(xiàn)方式十分類似于Oracle的in-memory db。

AlloyDB通過AI/ML引擎自動推薦列緩沖建議，用戶可以使用自動或者手動方式來建立列緩沖。實際上，HTAP中的AP不僅僅是列緩沖就能解決的，列緩沖只能解決一部分問題，OLAP數(shù)據(jù)庫產(chǎn)品有著更為復雜的索引與執(zhí)行器優(yōu)化機制。昨天一個朋友也質疑AlloyDB在AP上100倍的性能提升問題。我也仔細閱讀了谷歌官網(wǎng)的文檔，也認真看了一些體驗者的實驗。

谷歌的官方說明是具體提升的倍數(shù)是和應用場景相關的，他們目前也在通過進一步的優(yōu)化，從而讓各種場景都能有更大的性能提升。這說明100倍不是覆蓋所有的場景。我看了一些案例，大多數(shù)是邏輯比較簡單的超大表的查詢或者全表掃描，分組統(tǒng)計，并沒有特別復雜的多表關聯(lián)。對于AlloyDB的理解我也還比較膚淺，只不過在多年的數(shù)據(jù)庫應用經(jīng)驗中，我看到了一種全新的云原生數(shù)據(jù)庫設計方案，我覺得我們的數(shù)據(jù)庫架構師能夠認真研究一下，應該是能從中學到不少好東西的。