在企業、學校和各類服務提供商的計算中心建設中，數據庫的搭建具有重要的地位。而為了滿足應用的需求，需要不斷地提高和更新硬件設施，這是一筆巨大的開銷。并且隨著數據量的增加和服務請求的增長，傳統數據庫將會面臨諸多問題：
1)可擴展性差：傳統數據不是為大規模可伸縮的分布式處理設計的，雖然也提供復制和分區的解決方案，但不能從根本上解決問題，并且非常難以安裝和維護，甚至要犧牲一些傳統RDBMS(Relational DataBase Management System：關系型數據庫)的重要特性，不滿足彈性需求的要求；
2)海量數據條件下讀寫性能低下：當數據或并發用戶超過某個數量級后，性能上會有明顯下降，不能滿足高并發讀寫的服務請求；
3)管理復雜困難：傳統數據庫的維護要求人員專業性強，管理人員要進行嚴格的培訓，對數據的管理和維護復雜；
4)運行維護成本高：傳統數據庫很難進行升級和更新，當現有數據庫不能滿足應用需求的時候一般是全部采用新的更強大的硬件和新版本的軟件，這樣不僅需要巨大的開銷，還會使數據庫暫停服務，在很多場合這是不能容忍的。
1、云數據庫技術的發展和優點
傳統數據庫在一定程度上滿足了目前傳統的應用需求，但是由于其自身的缺陷和信息技術的發展，特別是在云計算平臺上海量數據的管理和應用的背景之下，云數據庫成為新一代數據庫的發展方向，研究云數據庫具有重大的意義。
云計算按照服務類型大致可以分為三類 ：IaaS(Infrastructure as a Service：基礎設施即服務)、PaaS(Platform as a Service：平臺即服務)和SaaS(Software as a Service：軟件即服務)。云數據庫是在SaaS成為應用趨勢的大背景下發展起來的云計算技術，它極大地增強了數據庫的存儲能力，消除了資源的重復配置，讓軟、硬件升級變得更加容易。云數據庫具有高可擴展性、高可用性，采用多租戶形式和支持資源有效分發等特點。可以說，云數據庫代表著數據庫技術未來發展的一種主流方向。目前，對于云數據庫的概念定義不盡相同，文中云數據庫定義是：云數據庫是部署在云計算環境中的數據庫。
在云數據庫應用中，客戶端不需要了解云數據庫的底層細節，所有的底層硬件和實現對客戶端而言是透明的，它就像在使用一個運行在本地的數據庫一樣，非常方便簡單，同時又可以獲得理論上近乎無限的存儲和處理能力。具有如下優點：
動態可擴展：理論上，云數據庫具有無限可擴展性，可滿足不斷增加的數據存儲需求。在面對不斷變化的條件時，云數據庫可表現出很好的彈性。如：對于一個從事產品零售的電子商務公司，會存在季節性或突發性的產品需求變化；或者對于網絡社區站點，可能會經歷一個指數級的增長階段。這時，就可以分配額外的數據庫存儲資源來處理增加的需求，其過程只需幾分鐘。一旦需求過去以后，就可立即釋放這些資源。
高可用性：不存在單點失效問題。如果一個節點失效了，剩余的節點就會接管未完成的事務。而且在云數據庫中，數據通常是復制的，在地理上也是分布的。諸如Google，Amazon 和IBM 等大型云計算供應商具有分布在世界范圍內的數據中心，通過在不同地理區間內進行數據復制，可以提供高水平的容錯能力。例如，Amazon SimpleDB 會在不同的區間內進行數據復制，因此，即使整個區域內的云設施發生失效，也能保證數據繼續可用。
較低的使用代價：通常采用多租戶(multi -tenancy)的形式，這種共享資源的形式對于用戶而言可以節省開銷；而且用戶采用按需付費的方式使用云計算環境中的各種軟、硬件資源，不會產生不必要的資源浪費。另外，云數據庫底層存儲通常采用大量廉價的商業服務器，這也大大降低了用戶開銷。
易用性：使用云數據庫的用戶不用控制運行原始數據庫的機器，也不必了解它身在何處。用戶只需要一個有效的鏈接字符串就可以開始使用云數據庫。大規模并行處理：支持幾乎實時的面向用戶的應用、科學應用和新類型的商務解決方案。
2、主流的云數據庫產品和比較
經過近幾年的發展，各企業根據自身的業務需求和數據特征設計了各自的云數據庫，通過對當前云數據庫市場的調查，結果如表1 所示。
使用云數據庫平臺可以直接采用Amazon、Microsoft、Oracle 的云存儲解決方案，但是建設這樣的平臺代價很大，對經費要求很高。同時也可以采用HBase、Hypertable 等開源的解決方案，這雖然免費并且可以根據自身應用做相應的優化，但是對技術要求很高，后期開發具有一定難度。為了選取合適的云數據庫，對各個產品進行了對比。
2.1 Amazon 的SimpleDB
SimpleDB是Amazon 提供的簡單數據庫服務，主要用于存儲結構化數據，并為數據提供查找、刪除等基本的服務，其具體的實現細節Amazon 沒有公開。由于Amazon 主要是提供商業性的服務，使用其服務需要一個Amazon 的帳戶，那么一個用戶帳戶就相當于全集，而具體的數據則相當于子集。由于SimpleDB簡單的數據存儲方式，其所有的數據都是以字符串形式存儲，導致其采取詞典順序進行查詢，數據操作很不方便。考慮到其技術封閉性，不能在實驗環境中使用其平臺。
2.2 Google 的BigTable
BigTable是Google 基于GFS (Google File System)和Chubby 開發的分布式存儲系統。BigTable 是非關系型數據庫，是一個稀疏的、分布式、持久化存儲的多維度排序表。它采用行鍵(row key)、列鍵(column key)和時間戳(timestamp)對表進行索引。表中的每個值都是未經解釋的字節數組。BigTable 在行鍵上根據字典順序對數據進行維護，并且一張表的行鍵也是其劃分行區間，進行Split 和負載均衡的依據。其設計目的是可靠地處理PB 級的數據，并且能夠部署到上千臺機器上。BigTable 已經實現了下面的幾個目標：適用性廣泛、可擴展、高性能和高可用性。BigTable已經在多個Google 的新產品和項目中得到了應用，如Google Analytics 和Google Earth 等。
根據對BigTable 的研究，了解到BigTable 主要是Google 針對自身各種應用設計的存儲系統，并且沒有開源，在實驗中無法使用。但是BigTable 的主要技術和實現都對外開放，并且BigTable 的研究資料非常豐富，在研究云存儲的過程中具有很高的借鑒意義和參考價值。
2.3 Microsoft 的SQL Azure
SQL Azure 是微軟的云關系型數據庫，是基于SQL Server 技術構建的，主要為用戶提供數據應用服務。SQL 簡化了數據庫的部署，用戶無需安裝和配置數據庫，也不需進行維護和管理。并且，SQL Azure 還為用戶提供高可用性和容錯能力。SQL Azure 做為一個商用數據庫，其提供一個云端的DBMS(DataBase Manager System)，這使得本地應用和云應用可以在微軟的數據中心的服務器上存儲數據。用戶是按需付費，其中主要的費用是操作費用，而不是磁盤和DBMS 軟件投入的費用。
SQL Azure 做為一款商業軟件，其采用按需服務、按需收費的模式。由于其不開源，所以無法在實驗環境中搭建，但是做為云數據庫中采用關系型數據模型的典型代表，依然具有重要的研究意義。
2.4 Apache 的HBase
HBase數據庫是基于Hadoop 的Apache 頂層項目，它是BigTable 的開源實現，但存在很多不同之處。HBase 是一個在HDFS 上開發的面向列的分布式數據庫，主要支持實時的隨機讀寫超大規模數據集。HBase是自底向上地進行構建，能夠簡單地通過增加節點來達到線性擴展。HBase 是非關系型數據庫，不支持SQL 查詢，但其具備了RDBMS 無法比擬的特性：在廉價硬件構成的集群上管理超大規模的稀疏表。HBase系統結構如圖1 所示。
HBase 采用一個Master 節點協調管理一個或多個RegionServer 從屬機(HBase 把表水平劃分成Region“區域”)。HBase 主控機(master)負責啟動和注冊RegionServer，把Region 分配給RegionServer 并負責RegionServer的故障恢復。RegionServer 負責Region 的管理和響應用戶的讀寫請求，當有新的Region 產生時，RegionServer 將通知Master 節點。
HBase 依賴于Zookeeper(Zookeeper 提供分布式鎖服務，類似Google 的Chubby)，它管理一個Zookeeper實例，作為集群的“權威”(authority)，并負責根目錄表的位置、當前集群主控機地址等重要信息的管理，并負責維護整個集群的工作狀態和災難恢復。
HBase 是開源實現，可以方便地從互聯網上下載安裝包和源代碼，非常適合企業、科研單位和學校進行使用學習和再開發。但其操作和管理界面比較簡單不夠友好，需要進一步提高。
2.5 云數據產品比較結果
通過對幾種具有代表性的云數據庫進行研究，比較結果如表2 所示。
3、實驗
綜上所述，決定采用HBase 做為研究云數據庫的實驗平臺。
HBase 的安裝可以分為三種模式：單機模式、偽分布式模式和完全分布式模式。文中采用完全分布式模式，這樣可以模擬實際網絡環境，能夠體現云數據庫的特性，使實驗結果更具有說服力。
3.1 實驗環境的搭建
在實驗環境中共有6 臺服務器，搭建完全分布式HDFS 與HBase 環境，采用hadoop0.20.0 與HBase0.92.0 版本，其中二臺節點做為Namenode 和Master 節點，另外四臺做Datanode 和RegionServer，并且在其上運行Zookeeper 服務。整個實驗環境如圖2 所示。
在安裝Hadoop 和HBase 之前要在系統中安裝JDK 并配置好環境變量。在用戶目錄下安裝好Hadoop和HBase 之后，進入Hadoop 目錄下輸入命令：
rm / tmp/ *
bin/ hadoop namenode – format
bin/ start-all.sh
來啟動HDFS，可以使用bin/ hadoop dfsadmin – report來查看HDFS 的可用資源、實際使用百分比和Datanode的運行情況。
HBase 是運行在HDFS 之上的，所以必須確保HDFS 處于正常運行狀態。同時因為存在版本兼容性問題，在啟動HBase 之前必須讓HBase 確定使用Hadoop的版本，需要把Hadoop 目錄下的hadoop-0.20.2-core.jar 替換掉HBase/ lib 目錄下的hadoop-core-1.0.0.jar。最后確保集群中每臺的時間保持相對一致(誤差小于30 秒)，進入HBase 目錄輸入命令bin/ start-hbase.sh 啟動HBase。用命令bin/ hbase shell 進入外殼程序，用命令status 查看HBase 的狀態。
3.2 實驗詳解
在完成實驗環境的搭建之后，為了對HBase 官方描述的HBase 系統具備的特性進行驗證，設計了一些實驗對HBase 集群進行初步的測試：
1)海量數據的存儲
HBase 提供JAVA 編程API，在Eclipse 環境下編寫數據庫寫入程序，并且遞增數據寫入量，查看所需的時間，對性能進行簡單的分析。
根據HBase 存儲的特點，因為HBase 是對Rowkey進行排序的，隨機Rowkey 將被分配到不同的region上，這樣能發揮出分布式數據庫的優點。而Value 對于HBase 來說不會進行任何解析，其數據是否變化，對性能是不應該有任何影響的。同時為了簡單起見，所有的數據都將只插入到一個表格的同一個列中。
數據插入性能測試的設計場景是這樣的：取隨機值的Rowkey 長度為2000 字節，值的Value 長度為4000 字節，每次插入10000 條數據，直到1000 萬條結束。實驗建立的表名為TestData，實驗開始后可以從
http：//master：60010 查看進展。
結果表明從數據剛開始寫入時，只存在1 個Region，隨著數據達到一定的規模之后TestData 開始分裂，并實現負載均衡，把Region 平均存放在Datanode中。
HBase 不僅支持自動的負載均衡和副本容災機制，并且讀寫性能也很優秀，通過對上述實驗數據寫入時間的統計，數據寫入速度達到0.47ms/ 條(2127 條/秒)，并且在理論上還有很大的提高可能，因為實驗用的數據庫寫入程序為單線程，沒有采用MapReduce 并行編程模型。如果采用MapReduce 模型，寫入速度將會有很大程度的提高。這將在以后的研究工作中得到實驗驗證。
2)數據庫的動態擴展。
相對傳統的數據庫，云數據庫具有近乎無限的可擴展性，可以滿足不斷增加的數據存儲需求。在面對不斷變化的條件時，云數據庫可以表現出很好的彈性。為證明云數據庫具有的這個優勢設計了如圖3 所示的實驗。
首先用5 臺服務器建立一個云數據庫平臺，其中2臺Namenode 和Master，另外3 臺為Datanode 和RegionServer。啟動HDFS 和HBase，待系統正常運行之后查看HDFS 和HBase 狀態可以得到系統中正常的Datanode 和RegionServer 都是3 個。然后，在Namenode上注冊想要加入的節點IP 地址，于Hadoop 的conf目錄下的slaves 文件和HBase 的conf 目錄下的regionservers文件中添加新增節點描述，并把配置文件復制到整個集群的每臺服務器上。用start-all.sh 命令對整個HDFS 系統進行啟動，這時系統會對注冊Slave 的節點進行檢測。如果已經掛載那么則跳過，否則將在該節點上啟動HDFS 并掛載到系統中來。再運行starthbase.sh 把新添加的RegionServer 掛載到集群中。最后，可以看到整個HDFS 和HBase 的可用節點都動態地增加了。這種動態擴展性能能夠滿足動態的需求并在節能方面具有很大的優勢。
3)數據庫集群的抗毀性。
云數據庫的抗毀性是其中一個很重要的性能指標，主要體現在數據節點的容錯性和Master 節點的動態備份容錯。針對這兩點設計實現了如圖4 所示的實驗。
數據節點的容錯性實驗：在搭建好數據庫集群中創建表并寫入一定量的數據，手動進行負載均衡讓數據平均存放在每個節點中。然后，再在數據節點集群中kill 一定數量的節點，并檢測數據是否可用。結果是：當down 掉的數據節點小于集群配置dfs.replication的數據副本數時，該集群的數據始終保持可用。
Master節點的動態切換：Master 節點是管理數據的元數據表，表的查詢都要經過元數據表的索引，所以Master 節點具有唯一性，并且Master 必須要高可靠。設計如圖5 所示的實驗。
兩個節點同時運行HMaster 服務，其中一個為主Master，另一個為備份Master 并與主Master 保持同步。在數據庫集群正常運行的情況下，在主Master 節點中kill 掉HMaster 進程，集群在經過zookeeper.session.timeout 定義的時間之后，檢測到主Master 節點不可用，這時集群將進行Master 節點的切換，并且之前數據庫的數據不會丟失，整個集群依然可用。所以，備Master 在主Master 出異常不可用后將接替其管理HBase 數據庫的功能。
4、實驗結果
通過實驗可以看出HBase 在可擴展性、海量數據存儲、高可用性以及管理和運行維護方面具有很大的改進和提高。
在動態可擴展性方面：實驗表明HBase 在添加存儲節點對數據庫進行擴容的過程中，數據庫沒有停止服務，并且也不要求物理機具有相同的架構。說明HBase 的擴展是在線、動態具有彈性的。從而使得HBase 可用于提供彈性服務，在服務峰值動態加入大量節點用以滿足服務請求，提高服務質量。而在低谷時期則關閉大量節點，這樣可減少能量消耗降低成本。海量數據的讀寫性能方面：由于HBase 是基于HDFS 之上建立的，所以也繼承了其Map/ Reduce 的計算模型，這使其具有優秀的讀寫性能。淘寶網通過優化HBase 使得在數億條商品數據中查詢指定商品的時間可以達到毫秒級。
高可用性方面：傳統數據庫設計時是考慮如何避免故障的發生，而HBase 則是以大的集群為出發點，把故障做為一個常態來進行對待。HBase 采用多Master節點同時運行的策略：其中一個Master 為主Master 提供服務，而其它的Master 節點則保持與主Master 的同步，當主Master 出錯之后由Zookeeper 選舉產生新的主Master 繼續提供服務。對RegionServer 而言只要不同時有大于副本數目的節點失效則可保證數據一定可用。
另外，在低成本和易用性方面HBase 對傳統數據庫也有很大的優勢。硬件方面HBase 只要求使用普通的商用服務器即可，軟件則是開源，節約了大量成本。并且，HBase 屏蔽了物理層，對于客戶端而言就像使用一個安裝在本地的數據庫，操作簡單，維護方便。
5、結束語
文中提出了可以使用云數據庫來解決當前傳統數據庫面臨的諸多問題，并用HBase 做了驗證性的實驗。通過實驗發現云數據庫除了可以提供傳統數據庫一樣的數據存儲服務以外，還解決了目前傳統數據庫面臨的問題，特別是在可擴展性方面具有無與倫比的優勢。云數據庫是未來數據庫發展的主流方向，可以做為企業單位、科研院所和學校數據庫的首選產品。
下一步實驗和研究工作主要集中在云數據庫性能的詳細測試和分析，并根據實際的應用場景進行性能的優化。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.guhuozai8.cn/
本文標題：云數據庫應用研究
本文網址：http://m.guhuozai8.cn/html/consultation/10839713204.html
相關文章
