最近花了點時間研究了下OceanBase，非常有意思，寫點東西記錄一下學到的東西。
參考文檔：https://github.com/alibaba/oceanbase/wiki/OceanBase%E6%9E%B6%E6%9E%84%E4%BB%8B%E7%BB%8D
OceanBase的產生背景
OceanBase最初是爲了解決淘寶網的大規模數據而產生的（數百億條的記錄、數十TB的數據、數萬TPS、數十萬QPS），傳統的如Oracle單機數據庫肯定無法支撐（加再多硬件也不行，RAC的可擴展性太差），於是乎，有段時間，淘寶就開始用MySQL取代Oracle，然後就是瘋狂分庫（通常的做法是根據某個業務字段,通常取用戶編號，哈希後取模，根據取模的結果將數據分佈到不同的數據庫服務器上，客戶端請求通過數據庫中間層路由到不同的數據庫服務器上），這種方式有如下弊端：
1）添加節點比較複雜，往往需要人工介入；
2）有些範圍查詢需要訪問幾乎所有的分區數據庫，性能變的更差；
接着Hadoop如火如荼，於是這些技術人員又在考慮是否可以使用HBase，但HBase有個致命缺陷：只能支持單行事務（HBase的體系架構可參考我的另一篇博文：http://blog.csdn.net/u010415792/article/details/8902746，因爲寫在HBase裏是針對某個HRegion，而HRegion是分佈在各個結點中，所以至多隻能保證單行事務的原子性），而淘寶的業務必須支持跨行跨表事務。
因此，需要開發出一個新的數據庫，即有良好的可擴展性，又能支持跨行跨表事務，於是OceanBase應運而生！
OceanBase的架構設計
通過分析發現，雖然淘寶在線業務的數據量十分龐大，但最近一段時間（例如一天）的修改量往往不多，因此，OceanBase決定採用單臺更新服務器來記錄最近一段時間的修改增量，而以前的數據保持不變，稱爲基準數據。基準數據以類似分佈式文件系統的方式存儲於多臺基準數據服務器中，每次查詢都需要把基準數據和增量數據融合後返回給客戶端。這樣，寫事務都集中在單臺更新服務器上，避免了複雜的分佈式事務，高效地實現了跨行跨表事務；另外，更新服務器上的修改增量能夠定期分發到多臺基準數據服務器中，避免成爲瓶頸，實現了良好的擴展性。
- RootServer：（存放元數據）管理集羣中的服務器，tablat數據分佈及副本管理。
- UpdateServer：存儲增量更新數據，往往和RootServer公用一臺物理服務器。
- ChunkServer：存儲基準數據，基準數據有多個副本（類似Hadoop）
- MergeServer：接受客戶端請求，合併UpdataServer和ChunkServer的數據返回給客戶端，並定期把UpdateServer上的數據合併到ChunkServer上。
架構分析
從上面可以看出，OceanBase融合了分佈式存儲系統和關係數據庫這兩種技術。通過分佈式存儲技術將基準數據分佈到多臺ChunkServer，實現數據複製、負載均衡、服務器故障檢測與自動容錯，等等；UpdateServer相當於一個高性能的內存數據庫，底層採用關係數據庫技術實現。OceanBase相當於GFS + MemSQL，ChunkServer的實現類似GFS，UpdateServer的實現類似MemSQL，目標是成爲可擴展的、支持每秒百萬級跨行跨表事務操作的分佈式數據庫。
OceanBase最大的亮點在於把寫集中到一個單點UpdateServer，這樣的好處是可以讓一致性和可用性兼得，實現跨行跨表事務，壞處是UpdateServer單點性能有可能成爲瓶頸，因此它的配置要非常非高(大內存+SSD+存儲Cache）。
