淘寶的OceanBase

OceanBase架構圖(引自 rdc.taobao.com)

OceanBase 是淘寶研發的一套分佈式 NoSQL 數據庫系統。具體它是什麼、怎樣實現的，能夠參考李震老師(花名楚材)的《OceanBase介紹》和楊傳輝老師(花名日照)的《Oceanbase – 千億級海量數據庫》。這裏我只是談一下本身的感想，若有謬誤，敬請指正。

OceanBase 相較於其它分佈式存儲系統，有一個特性是支持跨行跨表事務。這個特性太明星了，讓幾乎全部其它系統黯然失色。但實現這個是有代價和侷限 的，OceanBase 只能使用單機接受更新，也就是說它的 UpdateServer 只能有一個（或者準確地說，一組）。因爲 UpdateServer 失去了擴展性，OceanBase 的應用必須創建在單機可以知足增量更新和查詢性能需求（查詢能夠經過從機部分緩解）的前提下（或者硬件性能的增加快於性能需求的發展）。爲知足這一點，需 要對軟件和硬件都進行很好的優化，幸運的是從淘寶核心系統團隊成員的文章來看淘寶應該不缺這樣的專家，也不缺買設備的錢。值得一提的是，每一個公司看來都有 本身的基因，看到 OceanBase 我腦子裏就浮現出淘寶數據庫架構中單機 Oracle 掛一堆 MySQL 的景象，何其類似啊！

陽振坤老師（花名正祥）在《淘寶海量數據庫之二：一致性選擇》這篇文章中說 OceanBase 是支持強一致性的。若是 UpdateServer 沒有從庫的話， 可以很容易理解。但考慮到 UpdateServer 從庫也提供讀服務，且 UpdateServer 之間使用 binlog 進行同步，那麼還可否保證強一致性這一點我比較懷疑。也許會有其它的輔助機制來保證這一點，例如在 MergeServer 上作必定的策略。

在高可用性方面，對 RootServer 的說明較少，不清楚 OceanBase 有沒有實現 UpdateServer 宕機後的 Master 選舉。因爲使用 binlog 同步，可能宕機恢復方面仍是有一些風險的。

將 MergeServer 和 ChunkServer 部署在一塊兒是個很好的選擇，這樣查詢時可以利用必定的局部性。但除非根據業務需求很是精妙地部署，不然不可避免須要請求其它 ChunkServer 上的數據。我不知道它的查詢是 MergeServer->(UpdateServer, ChunkServer0, ChunkServer1...)，仍是 MergeServer->(UpdateServer, MergeServer0, MergeServer1)。不一樣的模式有同的優缺點，若是 ChunkServer 只作存儲的話，查詢的過濾、合併應該是在 MergeServer 上作的。若是選用第一種方式請求，ChunkServer 間傳輸的數據沒有過濾和合並，數據量較大；若是選用第二種方式請求，UpdateServer 的壓力可能會被放大，視 MergeServer 封裝的功能而定。

OceanBase 的介紹中沒有提到 Chunk 或者 ChunkServer 是否分主從，也沒有提到總體更新機制。考慮到更新是以批量方式合併到 Chunk 中，也許爲了簡化，Chunk 或者 ChunkServer 只是互備，沒有主從。爲了保證 ChunkServer 合併 UpdateServer 上凍結/轉儲數據時查詢的正確性，可能用兩階段提交，不過我想仍然是一個很複雜的過程。

早上起來就想到這裏，之後有問題再補充吧。

PS: 以前將楚材錯當成了陽振坤老師的花名，已更正之。