hbase

hbase的数据模型从逻辑上可以分类为键值存储或者是有序映射的映射。物理数据模型是基于列族的列式数据库，单个记录以键值形式存储。

HBase把数据记录保存在HFile里，这是一种不能更改的文件格式。因为记录一旦写入就不能修改，新值将保存在新 HFile里。在读取数据和数据合并时，数据视图需要在内存中重新衔接。

hbase的行键和mysql的聚集索引都是物理上按顺序存储，是同一类设计，聚集索引是最高效的，无论顺序还是随机访问。

hbase提供了单表扩展能力，一个表的数据可以透明的分片存储在多个物理机上。

mysql没有提供单表透明分片，可以透过一些mysql实例的前置代理来实现，按预定义的分片模式分布存取单表数据。同时牺牲了一些常见特性。而hbase主动牺牲这些特性来实现透明分片。

hbase的扫描时不需要客户端特别处理分片的，mysql则把分片后的复杂性交给了客户端处理。这是二者最大区别。从设计上来看两者完全可以互相模仿，当然mysql的索引优势是hbase不具备的。

hbase在提升伸缩性和性能同时，不断地模仿关系数据库，而mysql可以裁剪一些特性来变成hbase。

hbase提供行级事务。hbase透过一个隐含约束：同一行不同列族的的hfile必须在同一物理机上实现行级事务。

行键设计重点考虑负载均衡，不要出现热点分区。否则闲的闲死，忙的忙死。发挥不了hbase集群的作用

由于热点数据问题，可能使用hbase集群和一个单mysql实例比并没有多少性能优势。当然hbase还有可用，可靠性，海量在线数据等优势。这点mysql集群分片实现并不是天然支持的。需要配合一些代理实现分片的读写。

 

试想一个分片的mysql，即使是单表的查询如果支持全部关系库特性，对性能来说将是个噩梦。而hbase只提供行键scan。hbase索引只保存范围。

mysql可以考虑放弃非聚集索引，并指提供基于聚集索引的查询。mysql的b树索引对随机访问很友好。

 hbase的ACID

需要考虑ACID的场景：

• Read APIs
  • get
  • scan
• Write APIs
• put
• batch put
• delete
• Combination (read-modify-write) APIs
• incrementColumn

原子性：All mutations are atomic within a row.（即使是一行内的多个列族）

一致性，隔离性：

A scan is not a consistent view of a table，scan开始后，可能会读scan开始后更新的数据。

持久性：

All visible data is also durable data. That is to say, a read will never return data that has not been made durable on disk[