最近有個需求，要修改現有儲存結構，涉及查詢條件和查詢效率的考量，看了幾篇索引和HBase相關的文章，回憶了相關知識，結合專案需求，說說自己的理解和總結。
前幾篇文章重點介紹MySQL索引相關的知識，從索引優點、索引結構演化過程，到SQL查詢過程、執行計劃，再到最後的索引優化，錯過的朋友可以回顧下前幾篇文章：
後面會開始介紹HBase索引相關的，和MySQL對比下，以加深對索引的理解，本篇先介紹下HBase，它的一些特性和整體架構，為後面介紹索引做準備，通過介紹，你會了解到：
- 為什麼會出現HBase
- HBase的特性
- HBase的整體架構
部分內容摘錄了幾個博友的文章，最後會給出文章連結，感謝他們的精彩分析。
為什麼會出現HBase
任何一個技術的出現都是有原因的，瞭解它為什麼出現，以及它解決了什麼問題，更有助於理解它的特性和設計思想。
MySQL瓶頸
MySQL是一個關係型資料庫，有很高的資料一致性和永續性保證，當訪問量特別高時，特別是寫入操作，會有很大的O效能瓶頸。
雖然可以通過主從讀寫分離、分庫分表的方式解決，但隨著資料量不斷增大、併發不斷增高，MySQL應用開發越來越複雜，也越來越具有技術挑戰性。
另外，分表分庫的規則的設定都是需要經驗的，雖然有Cobar、MyCat、Sharding-JDBC、TDDL、DBProxy中介軟體層來遮蔽開發者的複雜性，但是避免不了整個架構的複雜性。
分庫分表的子庫到一定階段又面臨擴充套件問題，需求的變更可能又需要一種新的sharding。
MySQL的擴充套件性差、大資料下IO壓力大、表結構更改困難，正是MySQL開發人員面臨的問題，也是MySQL的瓶頸。
雖然有這些瓶頸，但對資料一致性要求特別高的業務，還是要使用它，但是有的應用場景不需要太高的一致性，在大資料量、高併發的業務中，可以選擇其他儲存方案。
NOSQL的出現
NoSQL資料庫種類繁多，但是一個共同的特點都是去掉關聯式資料庫的關係型特性，資料之間無關係，這樣就非常容易擴充套件。
NOSQL有如下特點：
- 模式自由：不像傳統的關係型資料庫需要定義資料庫、資料表等結構才可以存取資料，資料表中的每一條記錄都可能有不同的屬性和格式；
- 逆正規化：去除約束，降低事務要求，更利於資料的分散式儲存，與MySQL正規化相反；
- 多分割槽儲存：儲存在多個節點上，很好地進行水平擴充套件，提高資料的讀、寫效能；
- 多副本非同步複製：為了保證資料的安全性，會儲存資料的多個副本；
- 彈性可擴充套件：可以在系統執行過程中動態的增刪節點，資料自動平衡移動，不需要人工的干預操作；
- 軟事務：事務是關係型資料庫的一個特點，NoSQL資料庫不能完全滿足事務的ACID特性，但是能保證事務的最終一致性；
NOSQL有一些理論支援：
- CAP理論：就是平衡一致性、可用性、分割槽容錯性，因為最多隻能同時實現2個，需要做平衡取捨；
- BASE模型：Basically Availble 基本可用，Soft state 狀態可以有一段時間不同步，Eventual Consistency 最終一致性，不保證在任意時刻任意節點上的同一份資料都是相同的，但是隨著時間的遷移，不同節點上的同一份資料總是在向趨同的方向變化；
放上網上的一張圖，可以看到不同資料庫測試點不同：
上圖也根據顏色區分了不同的資料模型，這裡簡單總結下。
關係型資料庫：一直在介紹的MySQL，就不說了；
鍵值：內容快取，主要用於處理大量資料的高訪問負載，查詢速度快，但資料無結構化，通常只被當作字串或者二進位制資料，比如Redis、MemcacheDB；
列儲存資料庫：分散式的檔案系統，按列儲存，針對某一列或者某幾列的查詢有非常大的IO優勢，以列簇式儲存，將同一列資料存在一起，查詢速度快，可擴充套件性強，更容易進行分散式擴充套件，但功能相對侷限，比如BigTable、HBase、Cassandra；
文件型資料庫：儲存類似JSON格式的內容，可對某些欄位建立索引功能，是最像關係型的資料庫，Key-Value對應的鍵值對，Value為結構化資料，資料結構要求不嚴格，表結構可變，但查詢效能不高，而且缺乏統一的查詢語法，比如MongoDB、CouchDB；
HBase產生背景
上面提到，隨著資料規模越來越大，大量業務場景開始考慮資料儲存的水平擴充套件，海量資料量儲存成為提升應用效能的瓶頸，單臺機器無法負載海量的資料處理，隨之而來的出現了很多的分散式儲存解決方案，HBase就是其中之一。
HBase－－DataBase on Hadoop，基於分散式檔案系統上面建立的資料庫，HBase是面向列的開源資料庫。
開源團隊根據2008年Google釋出了一篇關於Google搜尋引擎BigTable的核心思想的論文，實現了基於分散式檔案系統的列資料庫。
隨後加入Apache基金會，成為Hadoop生態圈中的頂級專案被大家熟知。
HBase的特性
高效能
HBase中儲存了一套HDFS的索引，通過表名－>行健－>列族－>列限定符－>時間版本這一套索引來定位資料的位置，HBase為每一列資料維護了一套索引規則，對於具體某一具體條資料的查詢可以非常快速的通過B＋樹定位資料儲存位置並將其取出。
另外，HBase通常以叢集部署，資料被分散到多個節點儲存，當客戶端發起查詢請求的時候，叢集裡面多個節點並行執行查詢操作，最後將不同節點的查詢結果進行合併返回給客戶端，提高IO效能。
高可用
HBase叢集中任意一個節點當機都不會導致叢集癱瘓。這取決於兩方面原因：
第一方面，ZooKeeper解決了HBase中心化問題；
另一方面，HBase將資料存放在HDFS上面，HDFS的資料冗餘存放在不同節點，一個節點癱瘓可從其他節點取得資料，保證了HBase的高可用。
易擴充套件
Hbase的擴充套件性主要體現在兩個方面，一個是基於上層處理能RegionServer的擴充套件，一個是基於儲存的擴充套件HDFS。
無模式
使用HBase不需要預先定義表中有多少列，也不需要定義每一列儲存的資料型別，HBase在需要的時候可以動態增加列和指定儲存資料型別。
HBase的整體架構
Hbase在整個Hadoop生態圈的地位如下圖：
瞭解幾個概念
rowkey：Rowkey的概念和mysql中的主鍵相似，Hbase使用Rowkey來唯一的區分某一行的資料；
region：和MySQL的分割槽或者分片差不多，Hbase會將一個大表的資料基於Rowkey的不同範圍分配到不通的Region中，每個Region負責一定範圍的資料訪問和儲存；
timestamp：timestamp對Hbase來說至關重要，因為它是實現Hbase多版本的關鍵，在寫入資料的時候，如果使用者沒有指定對應的timestamp，Hbase會自動新增一個timestamp，timestamp和伺服器時間保持一致。相同rowkey的資料按照timestamp倒序排列，預設查詢的是最新的版本，可以指定timestamp的值來讀取舊版本的資料。
內部基本組成
Hbase的整體主要由zookeeper，Hmaster，HRegionServer，Hdfs檔案系統組成，由這四部分共同完成資料的讀取與寫入。
不同範圍的資料被劃分到不同地方，稱為HRegion，不同的HRegion被放在不同的主機上，當查詢資料的時候，只要根據rowkey先找到資料在那個範圍的HRegion中，就可以直接到那個HRegion中找到資料，查詢效率比傳統的資料庫快很多。
整體結構
1.HMater
- 在Region Split後，負責新Region的分配；
- 新機器加入時，管理HRegion Server的負載均衡，調整Region分佈；
- 在HRegion Server當機後，負責失效HRegion Server 上的Regions遷移；
2.Region Server
- Region server維護Master分配給它的region，處理對這些region的IO請求；
- HRegion Server管理了很多table的分割槽，也就是region；
3.Zookeeper
- ZooKeeper為HBase叢集提供協調服務，它管理著HMaster和HRegionServer的狀態(available/alive等)，並且會在它們當機時通知給HMaster；
- zookeeper中管理著hbase的後設資料，例如-root-的位置所在；
4.HDFS
- 資料檔案的存放處，由於其本身的分散式儲存機制，所以資料檔案很安全；
- hadoop的datanode最好和region在同一主機上，方便讀取資料，儘量避免網路資料傳輸；
這篇主要是個引子，下一篇重點介紹下HBase中的索引，以及設計rowkey的一些原則和技巧。
參考文章：
歡迎掃描下方二維碼，關注我的個人微信公眾號，檢視更多文章 ~