通俗地講，雲計算就是把基礎設施以服務的形式打包對外銷售，它是一種商業模式，而其中的雲存儲是技術難點。可以從兩個次元分析雲存儲系統的特性：功能和可擴充性，這是一個“魚和熊掌”不容易兼得的問題。不同的資料規模，不同的事務和一緻性要求，不同的系統故障容忍度，都可能導緻不同的存儲系統設計。國外的網際網路巨頭Amazon、Google、Microsoft、Yahoo都有各自的雲存儲系統，國内的淘寶也研發了自己的雲存儲系統Oceanbase，并開始應用到聯機事務處理OLTP（On-line Transaction Processing）和聯機分析處理OLAP（On-line Analytical Processing）業務。
 楊傳輝 作者楊傳輝，花名日照，淘寶存儲系統專家，熱衷于分布式存儲和計算系統設計，對分布式系統理論和工程實踐有比較深厚的了解。之前在百度作為核心成員主導或參與MapReduce、BigTable和分布式消息隊列等底層基礎設施架構工作。 |
雲存儲系統資料結構
為了保證存儲系統的可靠性，需要将資料複制為多份。當資料規模增加時，我們可能會對傳統的資料庫分庫分表以水準擴充，很多企業還開發了各自的資料庫中間層以屏蔽分庫分表規則。然而，在傳統的分庫/分表架構下，每一份資料隻能為一組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将在合适的時間點開源。相信通過業界同仁一起努力，一定能夠将雲存儲這個問題解決好！