一文讀懂GaussDB(for Mongo)的計算存儲分離架構
摘要：IDC認為，目前階段來看，企業亟待解決的是數字化能力提升，包括：與業務的深入結合能力；數據處理和挖掘能力；以及IT技術運營和管理能力。特別是數據處理和挖掘能力，因為數字化轉型推進企業從以流程為核心向以數據為核心轉型，對海量、異構、多類型的數據處理和挖掘能力是釋放數據價值的前提，對數據全生命周期的管控治理是釋放數據價值的保障。可以看出，資料庫作為數據的承載，企業的要求不再只是簡單的存儲功能了。
GaussDB(for Mongo)是華為雲自主研發兼容MongoDB4.0介面的文檔資料庫。基於共享存儲的存算分離架構，對於傳統MongoDB社區版有如下優勢：
- 秒級添加Secondary節點(相比社區版Mongo小時級添加Secondary節點)
- 基於WAL複製, Secondary節點無寫IO,從根本上解決社區版Seconary節點Oplog脫節問題
- Primary/Seconary無任何IO交互,Secondary節點個數理論無上限, 支援百萬OPS的讀事務能力
- LSMTree Compaction 計算/IO卸載到Compaction統一調度池,集中管理,不浪費用戶讀寫IO
- 基於共享存儲，Chunk分裂/遷移動作不引起真實IO，只更新路由元數據，秒級分裂/均衡
1.GaussDB(for Mongo)技術架構
1）容忍更多Shard宕機
與社區版MongoDB的`Share-Nothing`模式不同的是，GaussDB(for Mongo)採用`Share-Storage`架構，計算存儲分離。集群模式下，N個Shard節點，可以容忍N-1個Shard宕機。
某個Shard節點宕機後，其負責的數據由於存在於共享的存儲池中，因此不需要物理拷貝數據，只需要修改元數據路由資訊，即可被其他分片節點接管。
2）更快的分裂與均衡能力
此外，由於Chunk數據在存儲池中，Chunk的分裂與均衡不涉及到數據拷貝，可以做到分鐘級分裂與擴容，分裂與擴容對用戶的影響也遠比社區版MongoDB小。
3）百萬級讀OPS能力
GaussDB(for Mongo)副本集模式下，Primary/Secondary節點之間共享同一份資料庫文件。Secondary節點只複製Primary節點的WriteAheadLog以及LSMTree的結構變更資訊，並應用到記憶體中。Secondary節點沒有LSMTree的Compaction和Flush任務，因此對用戶的讀業務影響很小。
此外，由於`Share-Storage`的架構優勢，添加Secondary節點並不需要拷貝數據，添加Secondary節點的動作可以秒級完成。而Primary/Secondary之間只傳遞元數據變更，不傳遞WriteAheadLog，因此Secondary節點的個數即使變多，也不影響Primary節點的寫性能。Secondary節點可以水平擴展，支撐百萬級的讀OPS。
4）主節點IO卸載
LSMTree的寫壓力來源於三部分：
- 用戶的業務寫入導致的Memtable Flush
- 後台SST文件Compaction
- WAL的持續寫入
根據線上業務的實際測算，三者的IO資源消耗佔比為： 1:10:1。後台的SST文件Compaction佔了絕大部分IO頻寬，通過將Compaction任務集中化管理，從計算池卸載到存儲池，進一步減少了用戶計算節點的CPU和IO資源消耗。
5）GaussDB(for Mongo) 只讀節點設計
- 傳統社區版MongoDB副本集基於Oplog做數據複製，只讀節點需要鏡像主節點的所有寫IO操作。GaussDB(for Mongo) 的只讀節點和主節點共享同一份底層資料庫文件(LSMTree的SST文件)，只讀節點並不自己生成SST文件。
- 隨著業務數據的寫入，Compaction的不斷執行，LSMTree的當前版本(包含哪些SST文件)不斷更新，LSMTree的元數據更新(增刪SST文件的記錄)被同步到只讀節點執行。
- RocksDB中，數據的變更被持久化到WAL里，元數據的變更(增刪文件的操作, 叫做VersionEdit)被持久化到Mainifest里。RocksDB的數據和元數據是分開的，WAL流和VersionEdit流是並行的，沒有嚴格的先後順序。為了保證只讀節點和主節點完全一致的事件回放順序，WAL和VersionEdit流必須要合併成一個流，在雙流合併後，通過LSN就可以為每個事件(WAL的寫操作/VersionEdit)定序。
- 基於WAL+VersionEdit複製，而不基於Oplog複製
- 共享文件(sst/wal)的生命周期管理由主節點負責sst文件和wal的文件的生命周期由主節點負責。RocksDB中，SST文件通過層級的引用計數來維持不被刪除。如下圖，RocksDB的每個游標會維持SuperVersion，如下圖中的S0，S1，S2。每個SuperVersion會引用一個Version，一個Version代表LSMTree在不斷變形(通過增刪SST文件變形)的過程中，某個時間點的形狀，最新的Version就代表LSMTree當前的形狀。
- 在GaussDB(for Mongo)中，主節點會記錄所有隻讀節點在使用的Version，並為這些Version增加引用計數從而維持SST文件的生命周期。對於WAL，主節點會記錄所有隻讀節點中最老的LSN(`oldestLsn`)，最老的LSN來自於複製最慢的只讀節點。並刪除比oldestLsn還舊的WAL文件。
- 元數據變更通知，無論是oldestLsn還是只讀節點的當前在用的活躍的Version，都需要及時推進，這些元數據的變更是通過主從節點的定期心跳上報到主節點上的。主節點利用心跳數據對垃圾版本與WAL做清理。如下圖所示，在經歷一次心跳後，主節點發現Secondary0的Version0和Secondary1的Version0不再使用。刪除這兩個Version後，SST0的引用計數為0，表示SST0可以被刪除。OldestLsn也從100推進到了250，可以清理掉250之前的WAL。
- 只讀節點的memtable的釋放：主節點的Memtable不會實時Flush為SST文件。如果只讀節點不處理主節點的Memtable的話，只讀節點的數據就不是實時的，且存在數據一致性問題。只讀節點通過回放WAL到記憶體的Memtable中，來覆蓋SST文件與主節點的Memtable的Gap。上文介紹了只讀節點是不往共享存儲寫入數據的， 所以只讀節點上的 Memtable 最後的結局一定是被丟棄掉。但什麼時候丟棄這個 Memtable 就是一個問題。過早的丟棄，會造成SST文件與Memtable之間的數據不連續，存在Gap，過晚的丟棄會造成記憶體的浪費。只有當只讀節點識別到SST的數據已經完全能夠Cover某個Memtable時，這個Memtable才可以被丟棄。
- GaussDB(for Mongo)的只讀節點在每次應用VersionEdit後，檢查所有SST中的最大的LSN與Memtable的最小的LSN的關係，來決定是否要丟棄某個Memtable。
- 記憶體元數據的反向更新：傳統的複製，數據流從Oplog來，走一遍完整的資料庫Server層CRUD介面，再落到引擎層。這種邏輯和主節點上業務的寫入邏輯是一致的，因此Server層的一些記憶體元數據結構，在這個過程中就自然而然的得到更新了。但是當採用基於WAL的複製後，整個WritePath並不經過只讀節點的Server層。因此Server層的記憶體元數據更新，就是一個很大的挑戰。在這裡，只讀節點對每一條WAL做分析，如果WAL的內容會影響Mongo記憶體元數據，就會reload對應的元數據模組。
GaussDB(for Mongo) 基於Share-Storage架構，實現秒級Chunk分裂與均衡，對業務影響更小，水平擴展速度更快，能容忍更多節點宕機。只讀節點功能，實現了一份數據多計算節點共用的功能。極大的提升了存儲的利用效率，提高了計算節點的讀取數據能力。為了讓副本節點具有持續的讀擴展能力，整個只讀方案採用元數據的同步模式，在不降低主節點負載的情況下，極大的提升了整個系統的讀數據的處理能力。為3節點，5節點，乃至於15節點以上的副本集的工作提供了可能。
數據顯示，全球數據量將從2018年32.5ZB快速增長到2025年的180ZB。異構、智慧和融合的資料庫將成為金融、政府、電信等各行業數據基礎設施的關鍵支柱。華為GaussDB(for Mongo)，能消除企業各業務系統數據孤島，構建面向行業場景的數據建模、分析和價值挖掘能力，最終幫助企業實現數據價值挖掘和共享。
