最近看一本書，鈴木敏文的《零售的哲學》，裡面提到一個很有意思的觀點，711核心使命是提供便利，圍繞便利場景，提供一系列食品、ATM服務等，而不是和超市去PK貨物品種。
聯想到常見的NOSQL數據庫和傳統關係型數據的區別也有點類似；傳統關係型數據庫發展了幾十年，就像超市一樣，功能非常多，非常完善，也是進入到各個行業中去。NOSQL從一出生就是帶著解決關係數據中的某些場景的不突出/不擅長的使命。
另外一些新數據庫又思考著突破NoSQL的場景的限制，想著同時解決OTLP/OLAP，也有誕生了NewSQL或者HTAP的概念，典型的有TiDB/CockroachDB。
可以說，隨著技術的發展，尤其是硬件的更新，新的存儲和新的網絡，NOSQL數據庫有幾個趨勢：
1、融合和跨界是各個數據庫（NOSQL/NEWSQL/SQL）當前選擇，所以各個NOSQL數據庫相互之間重疊能力很多，但是未來是否有一個大一統的數據庫？這個未必。
2、數據庫場景化趨勢非常明顯，圍繞核心擅長的場景，去補齊和完善周邊生態和能力也顯得尤為重要。
講了這麼多NOSQL數據庫大的趨勢和概念，接下來我會梳理下常見的一些NOSQL數據庫關鍵能力和適合的場景。本文是第一篇，梳理HBase適合的關鍵能力和適合場景。
前面有一些相關文章，大家可以看看：
新數倉系列：Hbase周邊生態梳理（1）
新數倉系列：Hbase國內開發者生存現狀（2）
新數倉系列：開源組件運營（3）
HBase 和 Cassandra的淺談
數據庫存儲模型簡述
HBASE+Solr實現詳單查詢
HBASE關鍵能力和特性
1、無固定模式(表結構不固定): 每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一張表中不同的行可以有截然並的列。HBase中的數據都是字符串，沒有類型。
2、容量大：一個表可以有數十億行，上百萬列。當關系型數據庫的單個表的記錄在億級時，則查詢和寫入的性能都會呈現指數級下降，而HBase對於單表存儲百億或更多的數據都沒有性能問題。數據量大，並且表很寬。
3、數據多版本：每個單元中的數據可以有多個版本，默認情況下版本號自動分配，是單元格插入時的時間戳。
4、高性能：針對Rowkey的查詢能夠達到毫秒級別。
5、支持實時更新。
6、高併發：一般單節點，隨機寫2萬~5萬QPS，隨機讀1.5萬~10萬QPS。
7、隨機查詢、隨機範圍查詢。
8、水平擴展，性能線性擴展，幾千臺完全沒有壓力。
9、強一致性：
HBase是基於Google的bigtable的論文實現的列式數據庫，cap理論中更傾向於強調c（副本數據一致性）和p（分區容錯性）。對數據一致性有要求的優先選優HBASE，和他對應的是Cassandra，更強調a(可用性)和p。
10、列存儲：
列式存儲(Columnar or column-based)是相對於傳統關係型數據庫的行式存儲(Row-basedstorage)來說的。
行式存儲 | 列式存儲 | |
優點 | Ø 數據被保存在一起 Ø INSERT/UPDATE容易 | Ø 查詢時只有涉及到的列會被讀取 Ø 投影(projection)很高效 Ø 任何列都能作為索引 |
缺點 | Ø 選擇(Selection)時即使只涉及某幾列，所有數據也都會被讀取 | Ø 選擇完成時，被選擇的列要重新組裝 Ø INSERT/UPDATE比較麻煩 |
更詳細的列式存儲/行式存儲說明：
http://blog.csdn.net/youzhouliu/article/details/67632882
11、列簇：
列族的作用是，將那些數據量和屬性相似的列聚集在一起，以便我們給這些列定義一些共同的存儲方式屬性(e.g. 數據壓縮，保存到讀緩存中)
HRegionServer內部管理了一系列HRegion對象，每個HRegion對 應了table中的一個region，HRegion中由多 個HStore組成。每個HStore對應了Table中的一個column family的存儲，可以看出每個columnfamily其實就是一個集中的存儲單元，因此最好將具備共同IO特性的column放在一個column family中，這樣最高效。
Hbase中數據列是由列簇來組織的，所以每一個列簇都會有對應的一個數據結構，Hbase將列簇的存儲數據結構抽象為Store，一個Store代表一個列簇。
hbase表中的每個列，都歸屬與某個列族。列族是表的chema的一部分(而列不是)，必須在使用表之前定義。列名都以列族作為前綴。例如courses:history ， courses:math 都屬於 courses 這個列族。
列簇的特點：
一張表通常有一單獨的列簇，而且一張表中的列簇不會超過5個。
列簇必須在創建表的時候定義。
表的列簇無法改變。
每個列簇中的列數是沒有限制的。
同一列簇下的所有列會保存在一起。
列在列簇中是有序的。
列在運行時創建。
列只有插入後才會存在，空值並不保存。
列簇不能太多：
https://www.cnblogs.com/1130136248wlxk/articles/5503634.html
12、LSM：Log Structured Merge Trees(LSM)，LSM被設計來提供比傳統的B+樹或者ISAM更好的寫操作吞吐量，通過消去隨機的本地更新操作來達到這個目標，適合寫多讀少。
13、稀疏表：
對於為空(null)的列，並不佔用存儲空間，因此，表可以設計的非常稀疏；
14、動態列：
HBase的每個列都屬於一個列族，以列族名為前綴，如列article:title和article:content屬於article列族，author:name和author:nickname屬於author列族。
Column不用創建表時定義即可以動態新增，同一Column Family的Columns會群聚在一個存儲單元上，並依Column key排序，因此設計時應將具有相同I/O特性的Column設計在一個Column Family上以提高性能。同時這裡需要注意的是：這個列是可以增加和刪除的，這和我們的傳統數據庫很大的區別。所以他適合非結構化數據。
15、TTL歷史數據快速過期：
我們在HBase中存儲的記錄可能有一些是增速很快且又不需要永久保存的，比如大量的“系統日誌”，也許只需保存最近幾個月記錄便可。我們的存儲空間又很有限，尤其是HDFS這種多副本容災存儲。再加上HBase在存儲每一行數據時，分別要為每一列保存一份rowKey，如果一行有10列，光rowKey就要存儲10份，開銷可想而知。因此定期定量刪除的功能也就成了普遍的需求。
使用表格級的屬性：TTL（Time To Live），設置記錄的有效期，當前時間超過記錄有效期後該記錄將被自動刪除。記錄的有效期 = TimeStamp + TTL；
16、自動分區
HBase擴展和負載均衡的基本單位是Region。Region從本質上說是行的集合。當Region的大小達到一定的閾值，該Region會自動分裂(split)，當然也可能是合併(merge)，合併可以減少Region和相應存儲文件的數量
17、SQL能力：通過spark/phoenix支持SQL。
18、二級索引：支持本地二級索引和全局二級索引。
19、支持多種語言(Thrift)。
適合的場景
引用自Facebook總結：
1、storing large amounts of data（100s of TBs） 存儲大量的數據（100s TB級數據）
2 、need high write throughput
需要很高的寫吞吐量
3、need efficient random access (key lookups) within large data sets
在大規模數據集中進行很好性能的隨機訪問（按列）
4 、need to scale gracefully with data
需要進行優雅的數據擴展
5 、for structured and semi-strured data
結構化和半結構化的數據
6 、don‘t need full RDFS capabilites（cross row/cross table transactions,joins etc.）
不需要全部的 關係數據庫特性，例如交叉列、交叉表，事務，連接等等
梳理不全的地方，請大家留言補充！
閱讀更多 大數據和雲計算技術 的文章
