淘寶Oceanbase云存儲系統實踐

        通俗地講，云計算就是把基礎設施以服務的形式打包對外銷售，它是一種商業模式，而其中的云存儲是技術難點。可以從兩個維度分析云存儲系統的特 性：功能和可擴展性，這是一個“魚和熊掌”不容易兼得的問題。不同的數據規模，不同的事務和一致性要求，不同的系統故障容忍度，都可能導致不同的存儲系統 設計。國外的互聯網巨頭 Amazon、Google、Microsoft、Yahoo 都有各自的云存儲系統，國內的淘寶也研發了自己的云存儲系統 Oceanbase，并開始應用到聯機事務處理 OLTP（On-line Transaction Processing）和聯機分析處理 OLAP（On-line Analytical Processing）業務。

        云存儲系統數據結構

        為了保證存儲系統的可靠性，需要將數據復制為多份。當數據規模增加時，我們可能會對傳統的數據庫分庫分表以水平擴展，很多企業還開發了各自的數 據庫中間層以屏蔽分庫分表規則。然而，在傳統的分庫/分表架構下，每一份數據只能為一組 Master-Slave 節點服務，這就導致同一組機器節點存放了完全相同的數據，當其中某個節點發生故障時，只能通過所在機器組中的節點進行故障恢復，這樣的系統稱為同構系統。

        云存儲系統一般指異構系統，每份數據可以被動態分配到集群中的任意一個節點，當某個節點發生故障時，可以將故障節點原有服務動態遷移到集群中的任何一臺機器。只有實現系統異構才能發揮分布式集群的規模優勢，減少集群運維成本，適應云存儲系統數據量快速增長的需求。

        數據結構決定了云存儲系統的功能，云存儲系統的數據結構主要有兩種：分布式 Hash 表和分布式B+ 樹，如圖 1 所示。分布式 Hash 表通過比如一致性 Hash 的方式將數據分布到集群中的不同節點，數據隨機分布，不支持范圍查詢；而分布式B+ 樹的數據連續存放，支持范圍查詢，但是需要支持分裂和合并，實現相對較為復雜。

圖 1 云存儲系統分類圖

        常見的 Key-Value 系統的數據結構一般為分布式 Hash 表，只支持基本的 Put、Get 和 Delete 操作，比如 Amazon 的 Dynamo 和 S3 系統。而 Amazon Simpledb 按照 domain 進行數據劃分，規定同一個 domain 數據量不能超過 10GB，從而可以存放到一個數據節點，用戶只允許在同一個 domain 內部執行范圍查詢操作。Amazon 的云存儲系統看起來不完美，但相當實用。

        Google 的系統設計之初就強調可擴展性。從最初的 GFS 到 BigTable，再到后來的 Megastore、Percolator，Google 先將系統的可擴展性發揮到極致，以后再逐步加入分布式事務、SQL 支持等功能。這樣的設計得益于 Google 強大的工程師團隊和公司一直以來崇尚通用系統的文化。Google 的云存儲分為兩層：分布式文件系統 GFS 和分布式數據庫系統 BigTable，GFS 是一個帶有追加功能的分布式文件系統，BigTable 將事務的提交日志追加到 GFS 中做持久化。數據在 BigTable 內連續存儲，邏輯上構成一棵分布式B+ 樹，Megastore、Percolator 又在 BigTable 的基礎上加入分布式事務、索引、SQL 支持等功能。Google 的系統設計比較貴族化，可以遠觀，但模仿前請三思，比如將系統分成多層可能會增加用戶操作的延時，對工程師的設計編碼能力提出了更高的要求。

        Microsoft SQL Azure 是一個傳統數據庫廠商在云存儲系統設計上給出的答案。當數據量增長時，必然要求犧牲部分功能來換取可擴展性，這對于 Microsoft 是不愿意看到的。Microsoft 直接在原有的關系型數據庫 SQL Server 上進行分布式擴展，盡可能多地支持 SQL 功能，其功能非常豐富，但系統內部不支持 SQL Azure 實例的分裂和合并。因此，SQL Azure 內部也限制了單個 SQL Azure 實例允許的最大數據量，如 Business Edition 的最大數據量不超過 50GB。相比 Google 的系統，Microsoft 系統的擴展性較弱，但功能較強。

        云存儲系統的難點在于狀態數據的遷移和持久化，狀態數據也就是系統的事務提交日志。Google BigTable 通過分布式文件系統 GFS 持久化提交日志，Microsoft SQL Azure 直接將提交日志通過網絡復制到數據的多個副本，而 PNUTS 通過 Yahoo!內部的分布式消息中間件 Yahoo! Message Broker 持久化提交日志。Yahoo!沒有對外提供云存儲服務，但這樣的設計可擴展性也是相當不錯的。

        淘寶 Oceanbase 架構設計

        淘寶 Oceanbase 是從 2010 年 5 月開始研發的，其定位是解決淘寶內部在線業務的云存儲問題。我們在設計系統時，總是考慮現在及今后一段時間的需求。互聯網業務大致可以分為 OLTP 和 OLAP 兩類，對在線存儲的需求簡單歸納如下。

• OLTP：今后數據規模為千億級，數據量百 TB，要求幾十萬 QPS 和幾萬 TPS。
• OLAP：支持千萬級記錄的數據集上進行實時計算。
• 功能：支持范圍查詢，支持跨行跨表事務。
• 其他：5個 9 的可用性、自動故障處理、自動擴容等。

        OLTP 和 OLAP 業務對性能的要求使我們必須采用分布式方案。另外，淘寶的業務發展迅猛，傳統的分庫/分表方法帶來的擴容及運維成本太高，必須構建異構的云存儲系統。通過 進一步分析在線業務，我們發現互聯網在線存儲業務有一個特點：數據量雖然很大，但新增數據量比較小，每天新增數據量基本在 1TB 之內。此外，淘寶的業務面臨一些其他挑戰，比如需要高效支持跨行跨表事務，需要支持兩張幾億到幾十億條記錄的大表進行聯表操作。淘寶的海量數據以及復雜的 功能需求對存儲系統的設計提出了新的挑戰，關系型數據庫在數據量上有點兒力不從心，而云存儲系統又不能高效地支持復雜的功能要求。因此，需要融合關系型數 據庫的功能和云存儲系統的可擴展性這兩個優點。

        如何借鑒已有技術滿足淘寶未來一段時間內的云存儲需求？如果直接模仿國外的互聯網巨頭，比如模仿 GFS + BigTable，淘寶的團隊確實有一定的經驗。然而這樣的系統在兩年之內很難穩定，并且不能滿足跨行跨表事務等復雜的功能需求。既然在線業務新增數據量 比較小，那是否可以把最新修改的數據和以前的數據分離呢？

        答案是肯定的。淘寶 Oceanbase 將數據分成動態數據和靜態數據兩部分：動態數據的數據量較小，側重 TPS 和 QPS，采用集中式的方法存放到單個節點的高品質存儲介質，如內存和 SSD；靜態數據的數據量很大，側重存儲容量，采用分布式的方法將數據分布到多臺普通 PC 服務器的磁盤或者 SSD。由于動態數據的存儲介質成本較高，需要不斷地將動態數據合并到靜態數據中，從而分布到多臺機器以實現分布式存儲。

        淘寶 Oceanbase 系統架構大致如圖 2 所示。從圖 2 可以看出，系統有以下幾個主要模塊。

圖 2 Oceanbase 架構圖

• RootServer：負責數據定位、機器管理、負載均衡、全局表 Schema 信息管理等。
• UpdateServer：負責存儲動態數據，存儲介質為內存和 SSD。
• ChunkServer：負責存儲靜態數據，數據存儲 3 份，存儲介質為磁盤或者 SSD。
• Client：Oceanbase 提供的胖客戶端。

        寫事務只操作 UpdateServer，讀事務需要同時讀取 ChunkServer 和 UpdateServer。某些操作，比如 OLAP 分析型操作可能需要涉及多個 ChunkServer 上的數據，這時將引入一個新的 MergeServer 模塊將請求拆分到不同的 ChunkServer，合并每個 ChunkServer 的返回結果后執行排序、分組、分頁等操作。靜態數據在 ChunkServer 中保存三份，UpdateServer 通過 Linux HA 的方式進行雙機熱備以保證可靠性。RootServer 的訪問壓力很小，一般可以和 UpdateServer 部署在相同節點上，并采用相同的 Linux HA 方式。Oceanbase 的 UpdateServer 在同一個 IDC 機房采用實時同步的方式保證強一致性，這意味著寫事務只有等到主機和備機都操作成功后才返回客戶端。Oceanbase 支持跨 IDC 機房的異步準實時熱備，多個機房之間的數據延遲為秒級。

        Oceanbase 的靜態數據和 BigTable 類似，數據被分為幾十到幾百 MB 不等的子表，每個子表的磁盤存儲格式為 SSTable，通過 bloom filter、block cache、key value cache 等方式進行優化。SSTable 支持根據 column group 按列存儲，從而高效地支持 OLAP 分析。動態數據采用 copy-on-write 的方式實現了單機內存中的B+ 樹，在單寫多讀的應用場景下不需要加鎖。

        Oceanbase 靜態數據構成一棵分布式B+ 樹，動態數據為單機B+ 樹。與線下 MapReduce 批處理應用不同，在線存儲應用的更新量一般比較小，動態數據服務器不會成為性能瓶頸。這也就意味著，淘寶 Oceanbase 用一種更為簡便的方式在底層實現了和其他互聯網巨頭類似的B+ 樹數據結構，并且能夠高效地支持跨行跨表事務。當然，當數據量增長到萬億級或者數據更新更快時，需要考慮將動態數據服務器的方案由集中式修改為分布式。我 們也考慮過多 UpdateServer 方案的設計，但由于短期內看不到明確的需求，暫時沒有實現，目前我們認為可以通過硬件的方法，比如萬兆網卡、更好的 CPU、更大的內存和 SSD 來解決。

        Oceanbase 還實現了一些分布式系統中常見的特性，比如自動負載均衡、在線修改 Schema、內置壓縮解壓縮等。另外，Oceanbase 系統里面沒有隨機寫操作，因此天然適應 SSD 存儲介質，很好地彌補了磁盤的 IOPS 不足這個問題。

        Oceanbase 應用效果和經驗

        Oceanbase 首先應用在淘寶收藏夾并取得了明顯的效果。淘寶收藏夾最初采用 MySQL 分庫/分表的方式實現，通過使用 Oceanbase，機器數由原來的 16 臺主加上 16 臺備共 32 臺減少到 12 臺靜態數據服務器加上 2 臺動態數據服務器，大大節省了機器資源。另外，目前應用的很多問題在 Oceanbase 中是通過更好的架構來解決，單機層面基本沒做優化，相信后續還有很大的提升空間。在這過程中，我們也積累了一些經驗教訓。

• 選擇合適的技術。云存儲聽起來比較神秘，但實際上，對于大多數企業，需要設計好系統可擴展性發展的路線圖，當數據規模比較小，可以采用傳統的分庫分表的方式構建同構系統；當數據規模逐步增加時，可以考慮構建符合企業需求的異構系統。

• 細節決定成敗。云存儲更多地是一個工程問題，代碼質量、優化細節對系統的表現影響至關重要，淘寶 Oceanbase 的大多數代碼都被兩個以上的工程師 Review，我們也在減少 Cache 鎖粒度、減少上下文切換、減少內存分配和內存拷貝等方面做了很多細粒度的工作。

        展望

        Oceanbase 目前的主要工作是應用推廣，根據應用的需求來逐步完善 Oceanbase 系統，實現互聯網數據庫的構想。我們已經開始和淘寶的業務團隊開展了千萬級數據秒級實時分析的 OLAP 項目。另外，Oceanbase 還在考慮整合分布式 Blob 存儲系統。隨著應用推廣的深入和 Oceanbase 系統的優化，希望能在合適的時間進行數據庫新基準 TPC-E的測試。

        另外一個振奮人心的消息是：Oceanbase 將在合適的時間點開源。相信通過業界同仁一起努力，一定能夠將云存儲這個問題解決好！

        作者楊傳輝，花名日照，淘寶存儲系統專家，熱衷于分布式存儲和計算系統設計，對分布式系統理論和工程實踐有比較深厚的理解。之前在百度作為核心成員主導或參與 MapReduce、BigTable 和分布式消息隊列等底層基礎設施架構工作。

來自: www.programmer.com.cn