NoSQL選型及HBase案例詳解(轉)

標籤：style   http   os   io   使用   java   ar   檔案   資料   

從 NOSQL的類型到 常用的產品，我們已經做過很多關於NoSQL的文章，今天我們從國內著名的互連網公司及科研機構的實戰談一下NoSQL資料庫。
　　NoSQL一定程度上是基於一個很重要的原理—— CAP原理提出來的。傳統的SQL資料庫（關係型資料庫）都具有ACID屬性，對一致性要求很高，因此降低了A（availability）和P（partion tolerance）。為了提高系統效能和可擴充性，必須犧牲C（consistency）。

 

　　依據CAP理論，從應用的需求不同，資料庫的選擇可從三方面考慮：
　　考慮CA，這就是傳統上的關係型資料庫(RDBMS)。
　　考慮CP，主要是一些Key-Value資料庫，典型代表為Google的Big Table，將各列資料進行排序儲存。資料值按範圍分布在多台機器，資料更新操作有嚴格的一致性保證。
　　考慮AP，主要是一些面向文檔的適用於分布式系統的資料庫，如Amazon的Dynamo，Dynamo將資料按key進行Hash儲存。其資料分區模型有比較強的容災性，因此它實現的是相對鬆散的弱一致性——最終一致性。
　　SurDoc是書生公司自主創新的電子文檔雲端服務平台，它支援雲端服務和移動終端，基於國際標準UOML，是目前全球唯一能讓使用者無需安裝Office、PDF或其他軟體就能閱讀所有格式文檔的產品。書生網北京書生軟體公司副總裁兼CTO金友兵介紹了SurDoc開發過程中資料庫的NoSQL選型及使用經驗。
　　首先，金友兵認為資料模型是資料庫選型中首先要考慮的問題，SurDoc中主要有三類資料：
　　使用者自己上傳的文檔，採用Distributed File System儲存
　　使用者自己的文檔資訊庫，採用關聯式資料庫MySQL。
　　文檔本身的基本資料、分區資訊及儲存位置等，採用NoSQL資料庫。這部分資料的主要特點是資料量大並且資料結構比較簡單。這部分資料要保證CAP原理中的AP。
　　NoSQL資料庫的選型需要考慮以下幾方面：
　　資料模型及操作模型：應用程式層資料模型是行、對象還是文檔型的呢？系統是否能支援統計工作？
　　可靠性：更新資料時，新的資料是否立刻寫到持久化儲存中去了？新的資料是否同步到多台機器上了？
　　擴充性：你的資料量有多大，單機是否能容下？讀寫量要求單機是否能支援？
　　分區策略：考慮對擴充性，可用性或者持久性的要求，是否需要一份資料被存在多台機器上？是否需要知道資料在哪台機器上。
　　一致性：資料是否被複製到了多台機器上，這些分布在不同點的資料如何保證一致性？
　　事務機制：業務是否需要ACID的事務機制？
　　單機效能：如果持久化將資料存在磁碟上，需求是讀多還是寫多？寫操作是否會成為磁碟瓶頸？
　　負載可評估：是否支援負載監控？
　　初期MemcacheDB實踐
　　優點：
　　MemcacheDB利用Berkeley DB的持久化儲存機制和非同步主輔複製機制，使memcached具備了事務恢複能力、持久化能力和分布式複製能力，
　　非常適合於需要超高效能讀寫速度，但是不需要嚴格事務約束，能夠被持久化儲存的應用情境。
　　輸送量大，讀寫速度優秀，相容memcached介面
　　缺點：
　　只支援單向的主從複製方式，可用性差。由於存在命中率問題，有時無法正確讀，橫向擴充比較困難。
　　Redis實踐
　　資料庫也具有類似於MemcacheDB的問題，新浪微博採用的NoSQL資料庫是Redis，Redis的優點是效能很高。
　　TokyoTyrant實踐
　　優點：
　　讀寫速度和並發效能比較優秀，支援Memcached協議，而且支援通過雙主複製實現高可用性。
　　缺點：
　　需要通過用戶端實現資料分布，增刪節點時的資料重分布較難實現。與Surdoc採用的Distributed File System不能很好的配合，不太適合互連網應用。
　　CouchBase實踐
　　優點：
　　輸送量極高，讀寫速度極快，支援memcached協議
　　實測三個Couchbase節點可以達到12000以上的ops
　　缺點：
　　採用緩衝全部key的策略，需要大量記憶體；節點宕機時failover過程有不可用時間，並且有部分資料丟失的可能；在高負載系統上有假死現象
　　設計過程中應該盡量減少Key的位元，實際運營了一段時間，出現故障的機率較高。
　　最終選擇——Amazon Dynamo的開源實現Riak
　　優點：
　　完全的Dynamo實現，資料總是可寫
　　高可用：設計上天然沒有單點，每個執行個體由一組節點群組成，從應用的角度看，執行個體提供I/O 能力。一個執行個體上的節點可能位於不同的資料中心內，這樣一個資料中心出問題也不會導致資料丟失。
　　可通過增加節點提高叢集輸送量
　　後端儲存採用levelDB，不需要大量記憶體
　　實測三個Couchbase節點可以達到5000左右的ops
　　缺點：
　　不支援memcached協議，需要修改現有代碼；沒有完善的監控系統，需要自行實現
　　Riak技術要點：
　　資料定位使用一致性雜湊
　　Vector lock，允許資料的多個備份存在多個版本，提高寫操作的可用性（用弱一致性來換取高的可用性）
　　容錯：Sloppy Quorum, hinted handoff, Merkletree
　　網路互聯: Gossip-based membership protocol ，一種通訊協議，目標是讓節點與節點之間通訊，實現去中心化
　　此外，Riak還具有執行Mapreduce操作的能力：
　　Map過程在各個物理節點上並行的執行
　　Reduce過程在提交MapReduce的節點上並存執行
　　支援以Javascript和Erlang代碼編寫MapReduce過程
　　基於SurDoc系統的資料模型及各種應用情境，金友兵介紹的NoSQL資料庫大多數保證CAP原理中的AP，我們上面已經提到還有另一類以Big Table為代表的NoSQL資料庫，人人遊戲大資料研究組資料科學家林述民為我們介紹了Big Table的開源實現——HBase。
　　首先，根據官方定義，HBase並不是一個資料庫：
　　Apache HBase? is the Hadoop database, a distributed, scalable, big data store.
　　它是BigTable的開源實現，HBase用了大量的詞彙替代以前Google論文中的設計理念或者是設計概念，如果想深入瞭解HBase工作原理，一定要把這些詞從原文上找到出處或者是意義。以下是一些對應關係：

　　在整個Hadoop生態系統中，它位於HDFS的上層。

　　是整個HBase的總體架構圖，大概分為三個層次：最上面就是訪問HBase的一個用戶端，中間相當於RegionServer，可以管理最下層的Distributed File System，標準的配置是HDFS。三個層次之間是解耦的，好多人對此存在一些誤區。
　　Rowkey設計是使用HBase時最重要的一個環節，接下來林述民以通過對比NoSQL資料庫和關係型資料庫，說明了HBase的Rowkey設計會怎樣影響系統的效能。
　　例1：疏鬆陣列結構
　　比如我國的省市結構是一個典型的樹型結構：中國下面有北京、上海直轄市，還有廣州、山東這樣一些省，省下面還有市。採用傳統的關係型資料庫儲存是以下的方式：

　　用HBase設計這樣的儲存結構是這樣做的：

　　可能還是用這個主鍵標識一個地區，那邊還是有兩個列，但不再用打逗號的方式來存它的父節點或者子節點。因為HBase中的列可以在生產過程中定義，不需要預先定義好。對於一些稀疏的矩陣結構，這種儲存方式的優勢很明顯。
　　例2：多對多關係
　　比如學校的選課系統，一個學生可以選很多門課程，同時每門課程也可以有好多學生去選，是一個典型的多對多關係。傳統的關係型資料庫儲存：

　　HBase儲存方式：

　　這樣設計，可以實現每條記錄的動態擴充，很匹配真實的業務情境。
　　例3：Key代替索引
　　比如人人的廣告系統，一天就有十億條記錄。這些記錄怎樣儲存下來呢？一種方式就是直接放到檔案系統，包括使用者ID是什麼，名字是什麼，什麼時候做了什麼事。為了便於查詢，就必須要做索引，會降低效能。
　　在HBase中是這樣設計的：

　　表中左列是Key，第一部分是使用者標識，第二部分是使用者操作時間，第三部分是事件ID（靠前的在檢索時更有優勢，在設計時可以利用這點進行最佳化）。檢索的時候，首先找到這個Key在哪台伺服器上，用戶端再直接去那台伺服器中做一個很小範圍的檢索。存的時候也通過這個ID存到不同伺服器上面，所以輸送量非常大。
　　例4：熱點問題
　　使用者的社交關係儲存，大型互連網公司都會遇到這個問題。類似於前面的例子，在HBase中可以這樣設計：

　　但是這種設計會存在熱點問題，比如某個人可能有十萬個好友，一旦查詢到這個人，整個伺服器就死掉了。所以這個設計可以改進一下，可以把friend那一列的內容也放到Key中，這張表就變成兩兩之間的關係，熱點問題就可以解決了。
　　例5：關聯概念
　　接下來是一個資料分析案例，業務情境是這樣的：假設有一個搜尋引擎每天採集使用者大量的搜尋資料，怎樣知道使用者總是把哪些概念放在一起搜尋？在HBase中可以得到這樣的邏輯關係，其中T(n)是搜尋關鍵詞：

　　這種邏輯關係在關係型資料庫中是無法設計的，其儲存優勢在於列彈性，只有被一起檢索過的關鍵詞才會儲存下來，這也是傳統意義上列儲存的優勢。
　　通過這幾個案例可以知道在HBase中需要注意以下幾個問題：
　　避免熱點問題，分布式就怕不均勻。
　　HBase有分割的概念。一台伺服器如果儲存資料量很大，會把大表或者小表分成兩個更小的表，放在其他伺服器上，所以盡量要減少這些分割。
　　珍惜每一個位元組，可以節約資源，降低風險，而且可以減少I/O，使這個系統做到最佳。
　　HBase沒有外鍵，也沒有join和跨表的transaction。
　　接下來，中國科學院資訊工程研究所副研究員王樹鵬為我們分享了“新型NoSQL大資料管理系統（BDMS）開發和使用交流”。王樹鵬介紹說他接觸的項目多數是非互連網的應用，比如安全、交通行業。這些行業目前也面臨著大資料的考驗，但是當前很多流行的NoSQL資料庫對於他們來說並不適用，所以他們自主研發了一個NoSQL資料庫管理系統。
　　設計目標
　　系統具有高可擴充性：可通過增加節點線性
　　支援複雜資料類型統一儲存管理：結構化資料、半結構化資料及非結構化資料；文本資料、多媒體資料；針對多種類型業務資料進行統一組織管理和處理
　　支援多樣化的訪問類型，提供者標準化：檢索、統計分析、關聯處理及深入挖掘；需要對多種業務資料進行關聯綜合分析；提供標準的DDL、DML操作文法，支援JDBC、ODBC等操作介面；對資料檢索、統計、分析處理的即時性要求很高；檢索要求秒級響應；跨域檢索訪問

　　是整個系統的架構，其中資料庫管理平台的結構如下：

　　其中，可以通過管理引擎實現跨越資料管理。對外可以提供相應的DDL介面、DML的介面以及開發介面。
　　系統主要特色
　　Share-Nothing的分布式儲存和計算架構
　　異構多來源資料的組織管理：實現了結構化資料、非結構化文本及非結構化多媒體的統一儲存管理
　　支援異構資料的統一SQL查詢：支援對於結構化資料、非結構化文本的檢索和分析，該檢索和分析操作都可以通過SQL進行實現
　　豐富的資料訪問和處理模式
　　高效的檢索機制
　　異構多副本儲存和恢複機制
　　跨域資料管理和檢索：支援跨域部署，可以在多個物理地點建立多個資料中心，在此之上可以支援資料在資料中心之間進行移動，並且可以支援對於位於不同地區的資料進行全域檢索和訪問
　　應用情境
　　海量結構化記錄管理
　　處理海量小文件管理和處理
　　面向異構資料的智能搜尋和挖掘系統
　　成功案例
　　王樹鵬介紹說這個系統已經有了成功的應用案例，是國家某部委大資料管理項目。這個系統的主要需求是：
　　大量資訊記錄，每天產生約40億條(約4TB)；
　　資料保留備份副本，記錄資料保留半年；
　　可對資料進行精確、模糊查詢及統計，結果秒級響應；
　　可大量匯入結構化、非結構化資料；
　　最終達到的實施效果是：
　　採用分布式儲存架構（3個中繼資料節點+115個儲存節點）；
　　資料規模超過5000億 ，查詢回應時間為秒級；
　　資料保留2個副本，保證資料安全；
　　系統可用容量約2PB。

NoSQL選型及HBase案例詳解(轉)