OceanBase的變化

OceanBase 面臨的新挑戰

隨著 OceanBase（以下簡稱 OB）在淘寶的應用越來越廣泛，前端對數據的需求也提出了越來越嚴苛的要求。在應用系統和開發團隊的配合下，給用戶提供了很多額外的功能，給用戶帶來方便的同時，也給 OB 帶來了很多的挑戰。

以淘寶的收藏夾應用為例，從4月份上線到現在，我們增加了2倍的數據表，數據量（包括數據條目和每日更新條目）是上線初期的4倍，訪問量是上線初期的8倍以上。尤其是每年一度的1111光棍節，這一天不只是中國的網購節日，對淘寶各個應用及底層系統都是一次技術大考，OB 也不例外，我們需要為應用系統準備3倍以上的流量空間。當然，我們不能在活動前一天非常豪邁的對 IT 部的同事說：上三倍服務器！尤其是 OB 的架構中存在一個公認的單點——UpdateServer（以下簡稱 UPS）的情況下。最近一段時間，我們想了很多的辦法來提升系統的可擴展性和弱化瓶頸。

OB0.2.1的發布

這里請注意，我們擺了一個烏龍，假如你看到開源分支上出現了0.2.1和0.2.2兩個版本的話，0.2.1其實是更新的，它包含了0.2.2版本的所有功能。這兩個版本的規劃和應用需求的急迫程度有偏差，造成的結果就是版本較小的更晚發布，你完全可以直接了解0.2.1版本！

在0.2.1版本中，從功能和架構方面來看，我們主要做了以下這些更新。

UPS 支持轉儲

這是一個很重要的新特性，將 UPS 內存中的數據 DUMP 到 SSD 設備的 SStable 中。通過轉儲，釋放更新數據內存占用，同時 SStable 在 SSD 設備上也能提供可以接受的讀取性能，基本上解決了線上應用更新量的瓶頸。這個新特性已經應用在淘寶的多個應用中，更新量最大的一個應用每天每個 UPS 接受500GB 的更新數據。

支持按列存儲

我們提供了類似 column family 的機制，支持少量數據獨立存儲在一起，減少整行存儲訪問過程中可能帶來的 IO 讀取量放大。實現的方法有點特別，歡迎大家在代碼中發現。

查詢功能增強

OB 現階段通過服務端數據過濾的方式實現了文本的 like，實現了一個比較高效的文本匹配算法。同時，在服務端使用多路歸并的方法，實現了多個條件（條件之間是 AND 關系）的數據查詢。

數據 DUMP

OB 通過訪問固定版本數據，實現了數據全量 DUMP，DUMP 出的數據可以根據配置吐出文本文件。通過解析 UPS 的 CommitLog，實現了數據增量 DUMP，增量 DUMP 的周期可以在秒級別。在已有的線上應用中，需要想淘寶數據倉庫中提供的數據都已經通過 OB 進行了吐出，這些應用已經去除了對原有關系型數據庫的依賴。

多機房

OB 使用了一個單獨的進程（我們稱之為 lsync）解析 UPS 的 CommitLog，同時將其復制到另外一個機房的 OB 集群 UPS 上。而接受日志同步的 UPS 會進行數據回放，從而在兩臺乃至多臺 UPS 之間保證數據更新的一致性。而 ChunkServer（以下稱之為 CS）的數據是不變的，這樣 OB 就保證了多個集群之間的數據一致性。由于數據同步采用異步進程，這些集群可以分布在同一個城市乃至異地。這種簡單的機制保證了絕大部分情況下數據的容災需求，主集群現在可以通過手工命令進行切換，同時為數據的分布讀提供了基礎（這點很重要，下面要講的系統瓶頸優化有兩個都依賴這個功能）。根據線上實際的應用情況，同城兩個機房間的數據同步延時在毫秒級別。

系統瓶頸優化

0. 2.1 發布之后，根據運行情況和1111的要求，OB 又對這個版本進行了一些改造，主要針對線上出現的一些瓶頸。

雙集群流量分布

我們改造了 OB 客戶端，使之接受 OB 的 RootServer（以下簡稱為 RS）的調配，在兩個集群之間靈活的按比例調配讀取流量。我們先確定了一個固定長度的數組，例如100或者1000等等，并按照比例在這個數組中劃出相應的比例對照不同的集群，讀取請求將根據生成的一個隨機數取模之后落到這個數組的哪一個位置決定到哪個集群訪問，當然寫流量和寫之前有一致性要求的讀還是集中在一個集群上的。原本規劃的是多個集群流量分配，而不僅僅局限于兩個。但由于時間比較緊，多個集群復雜的集群失效處理很難在短時間內穩定，而且經過評估單個集群的性能上限大大提高，遠沒有達到性能極限，所以就暫時采用了當前的簡單方案。

單集群內讀流量分布

我們改造了 OB 的 MergeServer（以下簡稱為 MS），使之接受 RS 的調配，在一個集群的多臺 UPS 之間靈活的按比例調配讀取流量，分配方法類似多集群之間流量分配，當然寫流量以及寫之前有一致性要求的讀還是集中在一臺 UPS 上的。同時為了降低基準數據和更新數據合并對 UPS 的負載，我們在 CS 端也實現了類似的機制，將合并的讀取流量也按比例分配到了不同的 UPS 上。和上一個架構優化一起，這些流量調配都是可以在線調整的，這樣提升了整個集群的讀取擴展能力。由于 OB 的靜態數據讀取能力可以根據 CS 的擴展線性增長，而現在更新數據的讀取能力也基本上能夠根據集群數量和 UPS 數量做到線性擴展了，這樣 OB 基本上就消除了讀取數據的瓶頸，而這些對應用方都是透明的。

UPS 上行帶寬優化

在前一段時間，線上應用出現了 UPS 上行帶寬打滿千兆的情況，將網卡使用方式變化為雙 active 之后在短時間內再次接近預警值，不管我們有沒有做上面的兩個優化，這種情況都是應該改變的。通過分析，我們定位到了問題所在，采用了兩個手段，首先減少了在內存的 memtable 中更新數據的版本數量，其次在每次 UPS 返回數據前都對進行了多次更新的字段進行了版本合并。通過這些優化，UPS 的上行帶寬下降了40%以上，隨著多集群和多 UPS 的上線，UPS 的網絡出口瓶頸基本上也消除了。這個優化手段還帶來了一些意外效果，UPS 的 CPU 使用率也下降了，可見原有的數據序列化方式 CPU 占用比較高，這是下一步優化的方向之一。

合并調度優化

OB 的基準數據和動態數據合并是比較消耗性能的。通常來講，我們總是能在一天中找到業務的低峰期進行合并，但在光棍節那天情況就會有所變化，為此我們對這個合并的調度機制進行了優化，從 CS 和 UPS 兩端都進行了速度控制，在合并的同時保證不錯的訪問能力。同時，我們在多集群方案中加入了集群錯峰合并的方法，保證在合并的時候有一個到多個集群擁有全部的服務能力，在線上我們實際驗證了現有的合并調度機制，高峰期間集群仍表現良好。

UPS 轉儲文件的預熱

前面已經提到 UPS 支持更新數據轉儲至持久化設備，當然我們通常使用 SSD，但 SSD 相對內存訪問速度仍然有數量級的差距。為了進一步提升訪問速度，我們設計了一套轉儲文件預熱方案，利用數據轉儲為 SStable 之后尺寸大大減少的特點，我們可以用遠小于 memtable 的內存將轉儲數據加載進來，也能提供接近內存的訪問速度。當然，這個預熱的內存大小是有限制的，實際上是利用 CS 原有的 BlockCache 機制，而且為了不至于一下子將訪問扔到還很冷的 SSD 持久化數據，我們做了一個簡單的流量逐步導入的機制，保證數據漸漸熱起來。這套預熱方案已經編碼、測試完畢，但還沒有在實際應用中使用，不過也快了，歡迎大家嘗試。

下一步 OB 的方向

要做的東西還非常多，OB 只能根據應用的需求進行排序，同時兼顧架構的演進，下面是我們認為下個階段比較重要的功能特性：

OB 的 restful web 接口

OB 的接口現在還是比較難以使用的，同時有一個比較重的客戶端，相信各位了解過開源 OB 的同學對此也深有體會吧，這個問題嚴重阻礙了 OB 的推廣和發展。淘寶核心系統有國內很好的 Nginx 開發團隊，我們會合作提供 OB 的 restful web 接口，第一步可能僅僅提供類似 get、put、delete、scan 等簡單操作，時間大概是在2012年 Q1，后續將封裝復雜操作，最終會把一些簡單的 SQL 封裝進來，時間大概是2012年 Q2。

OB 與其他開源產品的整合

OB 作為分布式數據庫，其讀性能很大程度上依賴前端緩存，而緩存淘寶有自主開發的 TAIR，或者一些成熟的開源產品，例如 memcached、redis 等等。另外，數據庫都提供有類似 blob 字段等較大數據的存儲功能，而在 OB 中直接提供這種服務代價是比較昂貴的，淘寶有自主開發的分布式文件系統 TFS，比較適合提供這種存儲服務。而對這兩個功能加入，當然不會繼續使用客戶端的方式，這樣會使應用開發成本越來越高，也越來越不靈活。

在提供 OB 的 restful web 接口的同時，我們會將三種數據存儲需求進行整合，用戶將不再需要關注緩存數據同步、數據存儲、數據備份等等麻煩的問題，數據將以服務化的方式提供，這個模型在2012年 Q2 的時候會有雛形，我們也會及時開源出來與大家分享。

OB 集成 MapReduce

OB 當中現存在大量數據，這些數據都是要進入離線數據分析集群的，但有些分析工作數據同步的代價和所需的計算資源相比有些得不償失，另外公用分析集群有自己通用的調度方式，有時候對應用的反應不夠及時，而 OB 自身的存儲方式也能支持小數據量（百G或T級別）的離線分析，這就催生了我們將經典的 MapReduce 模型引入的想法。

拜 Hadoop 實現的靈活機制，我們可以方便地將 Hadoop MapReduce 架設到 OB 上，開發代價是實現幾個數據輸入輸出函數，現在已經開展了一些工作，做了一些實驗，后續會持續投入在這方面，2011年 Q4 會有一個簡單的雛形出來，請大家提出寶貴意見。

在線的大數據量請求

有些在線應用需要大數據量的分析，例如百萬級別的數據聚合、消重、公式計算等等，要求的時間效率在秒級別。這種需求不適用于M/R模型，簡單的數據庫運算又會有大表 join 的問題。OB 探索部分滿足這個需求，也和相應的業務部門進行了合作，牽涉到的修改主要是數據并發訪問、支持更豐富的 where 條件、運算函數、算法優化等等，原型已經有了，相對成熟的時候會放出來給大家，收集大家的意見和建議。

索引

在現在的 OB 架構中，索引部分功能由 Rowkey 替代，但總有一些需求是 Rowkey 無法滿足的，現在我們的替代方案是建立冗余表并利用 OB 更新具有部分事務性的特點保證數據表和索引表的數據一致。這種方式對應用方非常不友好，尤其是應用方索引維護較多的情況下。OB 會在下一個階段支持在線索引，時間點大概是在2012年 Q2。

更新能力擴展

如果數據更新可以放寬事務要求，OB 現在已經有了線上方案，有些應用已經接入多臺 UPS 并行寫入。后續將按照應用需求（包括大家的需求哦）決定是否支持分布式事務。

OB0.2.1將在11月更新到開源站點上，還有很多技術細節這里沒有談到，歡迎大家踴躍發掘，多提寶貴意見，謝謝！

來自: rdc.taobao.com