前言

　　
　　“云計算將帶來一場革命”。在如今這個概念滿天飛的時代，這是否又是一次商業炒作?本文不想對此進行評論，而更愿意關注這背后帶來的變化。技術革命一定是源于某項技術突破，那么云計算又是源于何?從技術的視角看，云計算所突破的就是海量存儲技術以及在此基礎上的并行計算技術的突破。正是這些突破，造就了諸如Google、Facebook、Twitter這些新興互聯網企業。另一方面企業信息系統正日益變得復雜與龐大，上述技術突破展現出來的幾乎無限的擴展、海量計算以及高可用的特性正是企業所迫切需要的。

　　本文將就企業信息系統中如何更好應用上述技術進行探索。在討論云存儲技術的之前，我們來回顧一下現在企業所使用的關系型數據庫所存在的問題。

　　一、關系型數據庫的問題

　　1970年IBM的Edgar F. Codd博士發表一篇著名的論文《一種用于大規模共享數據存儲系統的關系數據模型》，由此奠定了現在諸如Oracle、MSSQL、MySQL、Postgres等關系型數據庫的理論基礎。40年過去了，關系型數據庫不可辯駁地坐上了數據世界中的頭把交椅。如此成功的技術會有什么問題?

　　問題來自于訪問量急劇增長所帶來的可擴展性。所有具有最基本功能的關系型數據庫都會支持join操作，不過join操作可能會很慢。由于數據庫通常依靠事務來保證一致性，而事務需要鎖住數據庫的一部分，使之不能被其他用戶訪問。因為鎖本身意味著競爭同一數據的用戶會被放入隊列，等待獲得讀寫權限，這在高負荷的情況下可能會成為系統的死穴。

　　通常我們會用下面幾種方法解決上述問題：

　　提升硬件能力，如增加內存、用更快的處理器或硬盤，這被稱之為垂直擴展，可解一時之憂。

　　增加新的計算機，構成數據庫集群。不過，這樣就會在正常使用及故障時遇到數據復制與一致性問題。

　　更新數據庫管理系統的配置。例如要優化數據用來寫底層文件系統的通道。

　　審視自己的應用，優化索引、優化查詢。不過，當我們的應用達到這個規模的時候，恐怕不太會完全沒有做過索引和查詢優化。那么，只好重新審視所有數據庫的訪問代碼，想發現零星的可以調優的機會，這是一件相當頭疼的事情。

　　增加一個緩存層。現在我們又需要面臨更新緩存和更新數據庫的一致性問題了，對于集群來說，問題更加嚴重了。

　　審視我們想要的查詢，復制那些訪問頻率較高的數據，讓它們更接近于查詢想要得到的形式，這個過程被稱為反范式化，也就是說違反了Codd提出的關系模型12條準則。這時我們只能安慰自己說我們是生活在現實世界之中。

　　這一幕是何等熟悉，現如今的企業應用的規模已經遠不是Codd提出關系模型的年代所能夠想象的。TB級別的數據庫已經并不罕見，一些數據表動輒上億條記錄，甚至幾十億條記錄。筆者遇到的一位客戶僅每年增長的數據量就達到了3TB，要知道這一數據在5年前僅有大約500GB。這樣的數據量已經開始給構建在此之上的企業應用造成巨大的壓力。我們接下來看看云存儲技術又是如何解決這一問題的。

　　二、云存儲技術帶來什么

　　云存儲技術最早來源于那些互聯網企業，這也是可以理解的，畢竟這些企業所面臨的訪問量也是之前任何應用所不曾遇到的。從一個數據就可以得知：現在支付寶每天新增的記錄數為3億條。顯然這樣的數據量以及在此之上的運算，不是傳統關系型數據庫可以支撐的了。

　　這里所說的云存儲技術并非特指某項技術，而是一大類技術的統稱，一般來自只要是具有以下特征的數據庫都可以被看作是云存儲技術。首先是幾乎無限的擴展能力，可以支撐幾百TB直至PB級的數據;然后是采用了并行計算模式，從而獲得海量運算能力。簡而言之，就是當計算能力不足，無論是存儲還是運算，對于需求提出方而言，就是簡單的增加機器即可實現。更進一步的特征便是高可用性，也就是說，在任何時候都能夠保證系統正常使用，即便有機器發生故障。目前常見的符合這樣特征的系統，有Google的GFS以及BigTable，Apache基金會的Hadoop(HDFS和HBase)，最初來自于Amazon現在也屬于Apache基金會的Cassandra，此外還有MongoDB、CouchDB、Hypertable、Redis等等。

　　作為可擴展性是指系統架構可以讓系統提供更多的服務而不降低使用性能的特性。通過現有的機器增加硬件的容量、內存進行垂直擴展，是最簡單的達到可擴展性的手段，但這有個限度。而水平擴展則需要增加更多機器，每臺機器提供全部或部分數據，這樣所有主機都不必負擔全部業務請求。但軟件自己需要有內部機制來保證集群中節點間的數據同步。而云存儲技術所帶來的可擴展性幾乎是無限的，并且對于投資者而言投入(硬件投資)與產出(提供更多的服務)幾乎是線性的。

　　水平擴展說到底就是使用更多的主機來承擔運算。假設一臺主機在運行一年的時間里發生故障的概率是n，那么20臺主機在運行一年的時間里發生故障的概率則為20×n，由此看出當某個集群中主機的數量達到一定程度，在一年中發生故障的概率將會非常大，甚至每天有機器發生故障也不是危言聳聽。許多云存儲技術都將此作為基本的設計前提，因此云存儲技術天生具有良好的高可用性與容錯。

　　怎么樣?是否很誘人。這么好還不如把現在的這些企業應用都替換了。先別著急，享受這些好處也是有代價的。說到這里就不得不提Eric Brewer的CAP理論(2002年被理論證明)。依據這個理論，對于一個大規模分布式數據庫系統，有以下三個需求：

　　一致性(Consistency)：對于所有的數據庫客戶端使用同樣的查詢都可以得到同樣的結果，即使是有并發更新的時候也是如此。

　　可用性(Availability)：所有的數據庫客戶端總是可以讀寫數據。

　　分區耐受性(Partition Tolerance)：數據庫可以分散到多臺機器上，即使發生網路故障，被分成多個分區，依然可以提供服務。

　　CAP理論指出，同時只能具有這三個特性中的兩個。傳統的關系型數據庫所強調的是一致性(C)與可用性(A)，而在分區耐受性(P)的方面的支持十分有限，這一點從本質上揭示了上述關系型數據庫的問題。再來看云存儲技術，都特別強調了分區耐受性(P)從而彌補關系型數據庫在此方面的不足，接下來的區別就是選擇可用性(A)還是一致性(C)了，反正是不能都選。對于CP系統，放棄的是可用性(A)，你的數據將保持一致性，但如果有節點發生故障，仍然會有部分數據無法訪問;而對于AP系統，放棄的則是一致性(C)，那么你的系統就有可能返回不太精確的數據。

　　以上技術特點決定了云存儲技術有一些特別擅長的領域。例如訪問流量可能會非常大，即隨時訪問數據量非常大，從而需要大規模分布式部署。考察讀寫操作的比例，特別適合統計分析型工作，但是寫可能是密集型的。有時對于數據一致性要求并不高，即可以容忍當某個數據被寫入后，在一段合理的時間內可能會有部分用戶讀到的是寫入之前的數據，搜索業務就是一個典型例子。

　　但同時也有些計算領域并非云存儲技術擅長。例如事務密集型計算，這類計算對一致性要求非常高。相比讀操作，寫操作會頻繁持續發生。在企業中存在大量這種類型的計算。

　　通過以上分析，我們發現，“年輕的”云存儲技術并非完美無暇，看似“古老的”關系型數據庫在其面前并非一無是處。云存儲技術現在不是，將來也不應該是關系型數據庫的終結者。在我們為它所展現出來的那些令人激動的特性面前，必須冷靜分析，這是否就是企業運算所需要的?至少現在看來不是全部。

　　三、企業應用探索

　　顯然不是所有的企業計算都適合使用云存儲，采用關系型數據庫也許仍然是目前的最佳選擇。問題就變成了應該將其用在哪里?接下來將會列舉兩個目前特別適合采取云存儲技術的應用領域，這兩個案例都來自于筆者比較熟悉的商業應用領域。

　　領域一、數據倉庫

　　數據倉庫將集中來自幾乎所有業務生產系統的數據，對外提供企業的各種查詢報表以及數據分析。從功能看這是一個典型的統計分析型工作，日常大量發生的都是讀操作。另一方面需要周期性地從業務生產系統收集原始數據，并可能需要對其進行進一步的數據加工，這一過程是寫密集的。數據量無疑會是非常大的，實際生產中的數據倉庫通常需要保留幾年至十幾年的數據，可以達到TB級，其中一些數據表可能會達到幾十億條甚至更多的記錄數。以上這些需求特點決定了其特別適合采用云存儲技術。

　　領域二、企業統一資料庫

　　所謂企業統一資料庫，就是將企業運行中所基于的各種資料集中到一個應用系統中進行統一管理，再由這個系統以服務的方式，提供給所有需要的其它業務系統，所提供的服務除普通查詢外，還應該包含基于搜索引擎的資料搜索服務，包括商品(以及商品類別、品牌)、合作伙伴(供應商、客戶、加盟商等)、合同(采購合同、銷售合同、加盟合同等)等。在這個應用中讀操作發生的頻率將遠大于寫操作，尤其當其以在線方式提供資料服務時更是如此，例如為網店提供資料服務。

　　需要說明的是，筆者所在的海鼎公司對以上這兩個方向都已經做了相當的工作。企業統一資料庫的第一個版本已經完成開發，并將在今年10月份在東莞美宜佳投入使用。而下一代的數據倉庫解決方案已經完成了前期預研工作，開始進入開發設計階段。

　　應該說包括云存儲在內的一系列云計算技術都還處于剛開始的階段。就如IT歷史上的其它新技術一樣，在為我們展示出令人激動的新特性同時，還有很多不足。這些不足既包括技術本身還有很多有待完善的地方，也包括圍繞其的后續開發工具不足導致的進入門檻偏高，以及與傳統技術的融合程度不高等等。但這些并不妨礙它未來美好的明天，海鼎公司也愿意在此方面投入努力，為客戶不斷創造新的價值。
　　（文/李希明）