1.1為什么要設計這么一套新的存儲架構

現在互聯網時代，不管生活中存在什么問題，我們都想通過互聯網來快速的檢索到答案，并且希望查到的結果是有用的。在這個海量數據的時代，對于之前的關系型數據庫可采取的措施就是把收集的數據刪減后保存，比如保存近N天的數據，但是這樣沒辦法存儲幾年甚至更長時間的數據，也就無法對用戶歷史的行為進行分析。因此新的存儲架構就產生了，hadoop擅長存儲任意的、半結構化的甚至是非結構話的數據，它給用戶提供了數據存儲的無限空間，支持用戶在前擋的時候存儲和獲取數據，對大文件存儲、批量訪問和流式訪問做了優化。

1.2RDBMS的問題

RDBMS在存儲保留用戶、產品、訂單訂單信息的時候提供持久化的服務是很合適的。但是對于數據迅速增長的情況，RDBMS就不大夠用了。 RDBMS提供了ACDI的特性，代表用戶數據是強一致性，這樣的如果你的用戶量特別多，那么共享的數據庫服務器的壓力也會越來越大，增加服務器可以有一定作用，但是對中央數據庫CPU和I/O負載還是有一定壓力。我們減輕壓力的第一步增加并行讀取的從服務器，將讀寫分離，因為DB寫的請求遠少于讀的請求，用戶大多數是瀏覽操作，但是如果用戶量持續上升，這樣也會收到性能限制。接下來就需要增加緩存了，把都操作放在內存中緩存數據的系統里，但是這樣的問題無法保證數據的一致性，因為DB不會主動去更新緩存中的數據，這樣可以緩解讀操作的壓力，但是寫操作還是沒有解決。如果負載在幾個月內會增加一個數量級這時候我們用RDBMS的代價就比較昂貴了，MySQL這種數據庫適合于特定場景業務，而且短期不會被取代，只是我們開發一個新產品，能預料到系統擴展速度很快，那我們在設計段就應該希望所有功能都可以用。

1.3NoSQL（Not-Only-SQL）

RDBMS很適合事務性操作，但不適合超大規模的數據分析處理，而且它出現等待和死鎖的頻率與事務和并發的增加并不是線性關系，Hbase可以滿足這些需求。 NoSQL對系數矩陣、寬表、列式存儲的支持使數據在存儲的時候無需范式化，也可以避免查詢時用開銷很大的JOIN操作。使用智能的逐漸可以控制數據怎么去存儲和存儲到什么位置。可以使用行鍵的部分內容去進行檢索，和字典序坐部分為頭的索引效果相似，這樣的設計是性能不會因為數據增長而下降。

1.4結構

表、行、列和單元格

最基本的單位是**列**。一列或多列形成一**行**，由唯一的**行鍵**（rowKey）來確定存儲。反過來，一個**表**中有若干行，其中每列可能有多個版本，在每一個**單元格**中存儲了不同的值。

所有的行鍵按照字典序進行排序存儲

行鍵排序可得到想RDBMS的主鍵索引一樣的特性，意味著行鍵總是唯一的，并且只出現一次，否則就是在更新同一行。

---

一行由若干列組成，這若干列又構成了一個列族，這有助于構建數據局部邊界和其他一些特性。

自動分區

在HBase中擴展和負載均衡的基本單元是region，region的本質是以行鍵排序的連續存儲區間，如果region過大，系統就動態拆分，反之即使合并，減少存儲文件數量。 region拆分和服務相當于其他系統提供的**自動分區**。當一個服務器出現故障后，該服務器上的region可以快速回復，并獲得細粒度的負載均衡，因為當服務于某個region的服務器當負載過大、發生錯誤或被停止導致不可用時，系統會將該region移到其他服務器。

實現

數據存儲在**存儲文件**中，成為HFile。文件內部由連續塊組成，塊的索引信息存儲在文件尾部。當把HFile打開加載到內存的時候，索引信息會先加載到內存。每一個HFile都有一個快索引，通過以磁盤查找就可以實現查詢。現在內存的塊索引中進行二分查找，確定可能包含給定鍵的塊，然后讀取磁盤塊找到實際要找的鍵。 每次更新數據的時候，都先將數據記錄在提交日志中（HBase叫預寫日志），然后才會把這些數據寫入內存的memstore中。一旦內存中保存的寫入數據累計超過了一個給定的大小，系統就把這些數據移出內存作為HFile文件寫到磁盤中，數據移出內存之后系統會丟棄對應的提交日志，只保留為持久化的到磁盤的日志，系統將數據移出memstore寫入磁盤的似乎和，不必阻塞系統的讀寫，通過滾動內存中的memstore就剋有實現。 HBase中有三給主要組件：客戶端庫、一臺主服務器、多臺region服務器。可以動態增加移除region服務器，適應不斷變化的負載。主服務器主要負責用Apache Zookeeper 為region服務器分配region，Apache Zookeeper 是一個可靠的、高可用的、持久化的分布式協調系統。

總結

以上是生活随笔為你收集整理的HBase权威指南阅读——第一章的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。