HBase儲備知識一：相關基本信息

一.維度

　　1.數據模型

　　　　數據有多種存儲的方式，包括鍵值對【相似Map】、半結構化的列式存儲和文檔結構存儲。

　　2.存儲模型

　　　　內存仍是磁盤持久化能夠和RDBMS進行比較，它們一般持久化存儲數據到磁盤中。即便須要的是純粹內存模式，也仍舊有其餘方案。一旦考慮持久化存儲，就須要考慮選擇的方案是否影響到訪問模式。

　　3.一致性模型

　　　　嚴格一致性仍是最終一致性？問題在於存儲系統如何實現它的目標：是否必須下降一致性要求?雖然這種問題很粗淺，可是在特定的場景中會產生巨大影響。由於一致性可能會影響操做延遲，即系統響應讀寫請求的速度。這須要權衡投入和產出後獲得一個折中結果。

　　4.物理模型

　　　　分佈式模式仍是單機模式？這種架構看起來像什麼？是僅僅運行在單個機器上，仍是分佈在多臺機器上，但分佈及擴展規則由客戶端管理，換句話說，由用戶本身的代碼管理？也許分佈式模式僅僅是個過後的工做，而且只會在用戶須要擴展系統時產生問題。若是系統提供了必定的擴展性，那麼須要用戶採起特定的操做嗎？最簡單的解決方案就是一次增長一臺機器，而且設置好分區（這點對於不支持虛擬分區的系統很是重要），設置時須要考慮同時提升每一個分區的處理能力，由於系統的每一個部分都須要提供均衡的性能。

　　5.讀/寫性能

　　　　用戶必須瞭解本身的應用程序的訪問模式。是讀多寫少仍是讀寫至關，或者是寫多讀少。是用範圍掃描數據好，仍是用隨機讀請求數據更好？有些系統僅僅對這些中的一種支持的很是好，有些系統則對各類狀況都提供了很好的支持。

　　6.輔助索引

　　　　輔助索引支持用戶按不一樣的字段和排序方式來訪問表。這個維度覆蓋了某些徹底沒有輔助索引支持且不保證數據排序的系統（相似於HashMap，及用戶須要知道數據對應鍵的值），到某些可能經過外部手段簡單支持這些功能的系統。若是存儲系統不提供這項功能，用戶的應用應該能夠應對或本身模擬輔助索引。

　　7.故障處理

　　　　機器會崩潰是一個客觀存在的問題，須要有一套數據遷移方案來應對這種狀況。每一個數據存儲如何進行服務器故障處理？故障處理完畢以後是否能夠正常工做？這與一致性模式維度有關係，由於失去一臺服務器可能會形成數據存儲的空洞。甚至使整個數據存儲不可用。若是替換故障服務器，那麼恢復100%服務的難度有多大？從一個正在提供服務的集羣中卸載一臺服務器時，也會遇到相似的問題。

　　8.壓縮

　　　　當用戶須要存儲TB級的數據時，尤爲當這些數據差別很小或由可讀性文本組成時，壓縮會帶來很是好的效果，即能節省大量原始數據存儲。有些壓縮算法能夠將此類的數據壓縮到原始文件大小的十分之一。有可選擇的壓縮組件，有哪些壓縮算法可用。

　　9.負載均衡

　　　　假如用戶有高讀寫吞吐量的需求，就要考慮配置一套可以隨着負載變化自動均衡處理能力的系統。雖然這樣不能徹底解決該問題，可是也能夠幫助用戶設計高讀寫吞吐量的程序。

　　10.原子操做的讀-修改-寫

　　　　RDBMS提供了不少這類的操做（由於它是一個集中式的面向單服務器的系統），但這些操做在分佈式系統中較難實現，這些操做能夠幫助用戶避免多線程形成的資源競爭，也能夠幫助用戶完成無共享應用服務器的設計。有了這些比較並交換操做，或者說檢查並設置操做，在設計系統的時候能夠有效地下降客戶端的複雜度。

　　11.加鎖、等待和死鎖

　　　　衆所周知，複雜的事務處理，如兩階段提交，會增長多個客戶端競爭同一個資源資源的可能性。最糟糕的狀況就是死鎖，這種狀況也很難解決。用戶須要支持的系統採用哪一種模型？這種鎖模型可否避免等待和死鎖。

二.可擴展性

　　RDBMS很是適合事務性操做，但不見長於超大規模的數據分析處理，由於超大規模的查詢須要進行大規模的數據記錄掃描或全表掃描。分析型數據庫能夠存儲數百或數千TB的數據，在一臺服務器上作查詢工做的響應時間，會遠遠超過用戶可接受的合理響應時間。垂直擴展服務器性能，即增長CPU核數和磁盤數目，也並不能很好地解決該問題。

　　更糟糕的是，RDBMS的等待和死鎖的出現頻率，與事務和併發的增長並非線性關係，準確地說，與併發數目的平方以及事務規模的3次方甚至5次方相關。分區一般是一個不切實際的解決方案，由於它須要客戶端採用很是複雜的方式和較高的代價來維護分區信息。

　　一些商業RDBMS也解決過相似的問題，但它們每每只是特定地解決了問題的某幾個方面，更重要的是，它們很是的昂貴。而一些開源的RDBMS解決方案中，每每放棄了其中的一些甚至所有的關係型特性，如輔助索引，來換取更高的性能拓展能力。

　　問題是，爲了性能而一直放棄以上關係型特徵是否值得？用戶能夠反範式化數據模型來避免等待，而且能夠經過下降鎖粒度的方式來儘可能避免死鎖。數據增加時，無需從新分區遷移數據並內嵌水平擴展性的方法。最後，用戶還要面對容錯和數據可用性問題，採用提升擴展性的機制，用戶最終會獲得一個NoSQL的解決方案，更確切地說，HBase能夠知足這些需求。

三.數據庫的範式化和反範式化

　　不一樣的規模，常常須要設計不一樣的系統結構，對這種原則的最佳描述是：反範式化、複製和智能的主鍵。這就須要從新思考在相似BigTable的存儲系統中如何才能高效合理地存儲數據。

　　部分原則是採用反範式化模式，例如將數據以前存放在多張表中的數據存儲在一張表中，這樣在讀取的時候就不須要從多張表中聚合數據。或者預先物化所需的視圖，一次優化從而避免進一步的處理來提升讀取性能。

　　有很是多的方法來轉換一對1、一對多、多對多的關係，以適應HBase的底層架構。用戶須要充分理解HBase存儲設計的潛在能力，而後深思熟慮地決定用哪種實現方式。對稀疏矩陣、寬表、列式存儲的支持使得數據在存儲的時候無需規範化，同時也能夠避免查詢時採用開銷很大的JOIN操做聚合數據。使用智能的主鍵能夠控制數據怎樣去存儲以及存儲在什麼位置。因爲可使用行鍵的部份內容進行範圍檢索，行鍵做爲組合鍵設計時，與字典序左部分爲頭的索引效果類似。所以，正確的設計可以使性能不會由於數據的增加而降低，例如，當數據從10條增長到1000萬條時，系統仍舊能夠保持相同的讀寫性能【只限少許數據的rowkey讀寫】。