通俗地講，云計算就是把基礎(chǔ)設(shè)施以服務(wù)的形式打包對外銷售,，它是一種商業(yè)模式,，而其中的云存儲是技術(shù)難點?？梢詮膬蓚€維度分析云存儲系統(tǒng)的特 性：功能和可擴展性,，這是一個“魚和熊掌”不容易兼得的問題。不同的數(shù)據(jù)規(guī)模,，不同的事務(wù)和一致性要求,，不同的系統(tǒng)故障容忍度，都可能導(dǎo)致不同的存儲系統(tǒng) 設(shè)計,。國外的互聯(lián)網(wǎng)巨頭 Amazon,、Google、Microsoft,、Yahoo 都有各自的云存儲系統(tǒng),，國內(nèi)的淘寶也研發(fā)了自己的云存儲系統(tǒng) Oceanbase，并開始應(yīng)用到聯(lián)機事務(wù)處理 OLTP（On-line Transaction Processing）和聯(lián)機分析處理 OLAP（On-line Analytical Processing）業(yè)務(wù),。

        云存儲系統(tǒng)數(shù)據(jù)結(jié)構(gòu)

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

        云存儲系統(tǒng)一般指異構(gòu)系統(tǒng),，每份數(shù)據(jù)可以被動態(tài)分配到集群中的任意一個節(jié)點,，當某個節(jié)點發(fā)生故障時，可以將故障節(jié)點原有服務(wù)動態(tài)遷移到集群中的任何一臺機器,。只有實現(xiàn)系統(tǒng)異構(gòu)才能發(fā)揮分布式集群的規(guī)模優(yōu)勢,，減少集群運維成本，適應(yīng)云存儲系統(tǒng)數(shù)據(jù)量快速增長的需求,。

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

圖 1 云存儲系統(tǒng)分類圖

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

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

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

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

        淘寶 Oceanbase 架構(gòu)設(shè)計

        淘寶 Oceanbase 是從 2010 年 5 月開始研發(fā)的,，其定位是解決淘寶內(nèi)部在線業(yè)務(wù)的云存儲問題,。我們在設(shè)計系統(tǒng)時，總是考慮現(xiàn)在及今后一段時間的需求,?；ヂ?lián)網(wǎng)業(yè)務(wù)大致可以分為 OLTP 和 OLAP 兩類，對在線存儲的需求簡單歸納如下,。

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

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

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

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

        淘寶 Oceanbase 系統(tǒng)架構(gòu)大致如圖 2 所示,。從圖 2 可以看出，系統(tǒng)有以下幾個主要模塊,。

圖 2 Oceanbase 架構(gòu)圖

• RootServer：負責(zé)數(shù)據(jù)定位,、機器管理,、負載均衡,、全局表 Schema 信息管理等。
• UpdateServer：負責(zé)存儲動態(tài)數(shù)據(jù),，存儲介質(zhì)為內(nèi)存和 SSD,。
• ChunkServer：負責(zé)存儲靜態(tài)數(shù)據(jù)，數(shù)據(jù)存儲 3 份,，存儲介質(zhì)為磁盤或者 SSD,。
• Client：Oceanbase 提供的胖客戶端。

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

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

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

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

        Oceanbase 應(yīng)用效果和經(jīng)驗

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

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

• 細節(jié)決定成敗。云存儲更多地是一個工程問題,，代碼質(zhì)量,、優(yōu)化細節(jié)對系統(tǒng)的表現(xiàn)影響至關(guān)重要,，淘寶 Oceanbase 的大多數(shù)代碼都被兩個以上的工程師 Review,，我們也在減少 Cache 鎖粒度、減少上下文切換,、減少內(nèi)存分配和內(nèi)存拷貝等方面做了很多細粒度的工作,。

        展望

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

        另外一個振奮人心的消息是：Oceanbase 將在合適的時間點開源,。相信通過業(yè)界同仁一起努力,，一定能夠?qū)⒃拼鎯@個問題解決好！

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

來自: http://www./9252/