为什么没有以hbase作为存储引擎的关系型数据库实现?

一、为什么没有以hbase作为存储引擎的关系型数据库实现

SQL引擎都可以作为hbase的SQL层。但是作为关系型数据库，支持多表事务，的确基于hbase没有很好的解决方案。首先目前hbase的事务是针对单机region server单表行级事务，也就是客户端一次请求，将多笔记录作为一条日志针对一个region进行处理。成功则写入memstore，失败则wal回滚，所以事务操作并不复杂，但是若要在一次事务中实现多表写入，多机region一致性协同，这在hbase设计之初并没有考虑。

因此，若按照目前hbase的设计，写入不同hregionserver，再写入不同region的memstore记录，包括各个wal的记录，必须保证一致性，这就是region分布式一致性的名列前茅难，必须要有集群一致性机制，例如paxos或者raft，可是hbase没有，只有一个简单的master解决region分片后的迁移平衡问题。必须要具备表表之间，列簇之间的ACID特性，hbase并没有设计此处，他的master和region server在这些问题上基本没有任何前期预留的分布式扩展机制。

其次每次事务必然会有多次查询请求，如果用tps代表事务吞吐，那么qps就代表了一次tps内可能涉及数百次的查询，我们可以忍受1秒1个事务操作，但是查询不行，每次查询必须能在毫秒内完成，甚至更短周期，那么这就存在优化问题了，如果查询是热点数据在memstore或者blockcache中，这还好说，但是在多个hfiile的磁盘中扫描这就慢了，例如：hbase的lsm-tree的删除和更新都只是一条新纪录的标识，这种用空间换取写入性能的设计，另外的副作用就是增加查询量，过期数据在查询中都扫描出来，由扫描器自己去过滤。那么为了解决查询问题，就必须加大内存和使用固态磁盘来解决查询速度，这就是第二难，实际上hbase类lsm树的查询机制复杂度远高于写入，而且提升基础资源成本改善性能并不具有普适性，这就是另一个问题了！

或许LevelDB，rocksdb，这些轻量级的kv的查询性能比起hbase会更适合事务单元内的高密度kv查询，但hbase还是倾向于大吞吐kv写入和热点数据查询用于支撑实时流处理过程的流库连接。因此我认为hbase要是考虑在未来支持分布式rdbms，必须得彻底升级master服务支撑region server的分布式一致性，并且实现跨表的ACID特性支持，最后就是region级别的读优化。

延伸阅读：

二、MongoDB是什么

非关系型数据库(nosql ),属于文档型数据库。MongoDB采用类JSON的documents来存储数据。数据结构由键值(key=>value)对组成。

MongoDB采用动态数据模型schema，这意味着不需要预先定义表的数据类型和字段名。当MongoDB需要更新文档documents的时候，可以轻松增加新的字段名或者删除旧的字段。MongoDB让数据结构更加层级化，因而存储数组等复杂数据结构。 在同一个集合collection中，文档document对字段也没有强约束，因此更容易设计差异化的数据结构。