最近看一本书，铃木敏文的《零售的哲学》，里面提到一个很有意思的观点，711核心使命是提供便利，围绕便利场景，提供一系列食品、ATM服务等，而不是和超市去PK货物品种。
联想到常见的NOSQL数据库和传统关系型数据的区别也有点类似；传统关系型数据库发展了几十年，就像超市一样，功能非常多，非常完善，也是进入到各个行业中去。NOSQL从一出生就是带着解决关系数据中的某些场景的不突出/不擅长的使命。
另外一些新数据库又思考着突破NoSQL的场景的限制，想着同时解决OTLP/OLAP，也有诞生了NewSQL或者HTAP的概念，典型的有TiDB/CockroachDB。
可以说，随着技术的发展，尤其是硬件的更新，新的存储和新的网络，NOSQL数据库有几个趋势：
1、融合和跨界是各个数据库（NOSQL/NEWSQL/SQL）当前选择，所以各个NOSQL数据库相互之间重叠能力很多，但是未来是否有一个大一统的数据库？这个未必。
2、数据库场景化趋势非常明显，围绕核心擅长的场景，去补齐和完善周边生态和能力也显得尤为重要。
讲了这么多NOSQL数据库大的趋势和概念，接下来我会梳理下常见的一些NOSQL数据库关键能力和适合的场景。本文是第一篇，梳理HBase适合的关键能力和适合场景。
前面有一些相关文章，大家可以看看：
新数仓系列：开源组件运营（3）
新数仓系列：Hbase国内开发者生存现状（2）
新数仓系列：Hbase周边生态梳理（1）
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.） 不需要全部的 关系数据库特性，例如交叉列、交叉表，事务，连接等等
梳理不全的地方，请大家留言补充！
