一、為什么沒有以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對字段也沒有強約束，因此更容易設計差異化的數據結構。