一、為什么沒有以hbase作為存儲(chǔ)引擎的關(guān)系型數(shù)據(jù)庫實(shí)現(xiàn)

SQL引擎都可以作為hbase的SQL層。但是作為關(guān)系型數(shù)據(jù)庫，支持多表事務(wù)，的確基于hbase沒有很好的解決方案。首先目前hbase的事務(wù)是針對(duì)單機(jī)region server單表行級(jí)事務(wù)，也就是客戶端一次請(qǐng)求，將多筆記錄作為一條日志針對(duì)一個(gè)region進(jìn)行處理。成功則寫入memstore，失敗則wal回滾，所以事務(wù)操作并不復(fù)雜，但是若要在一次事務(wù)中實(shí)現(xiàn)多表寫入，多機(jī)region一致性協(xié)同，這在hbase設(shè)計(jì)之初并沒有考慮。

因此，若按照目前hbase的設(shè)計(jì)，寫入不同hregionserver，再寫入不同region的memstore記錄，包括各個(gè)wal的記錄，必須保證一致性，這就是region分布式一致性的名列前茅難，必須要有集群一致性機(jī)制，例如paxos或者raft，可是hbase沒有，只有一個(gè)簡單的master解決region分片后的遷移平衡問題。必須要具備表表之間，列簇之間的ACID特性，hbase并沒有設(shè)計(jì)此處，他的master和region server在這些問題上基本沒有任何前期預(yù)留的分布式擴(kuò)展機(jī)制。

其次每次事務(wù)必然會(huì)有多次查詢請(qǐng)求，如果用tps代表事務(wù)吞吐，那么qps就代表了一次tps內(nèi)可能涉及數(shù)百次的查詢，我們可以忍受1秒1個(gè)事務(wù)操作，但是查詢不行，每次查詢必須能在毫秒內(nèi)完成，甚至更短周期，那么這就存在優(yōu)化問題了，如果查詢是熱點(diǎn)數(shù)據(jù)在memstore或者blockcache中，這還好說，但是在多個(gè)hfiile的磁盤中掃描這就慢了，例如：hbase的lsm-tree的刪除和更新都只是一條新紀(jì)錄的標(biāo)識(shí)，這種用空間換取寫入性能的設(shè)計(jì)，另外的副作用就是增加查詢量，過期數(shù)據(jù)在查詢中都掃描出來，由掃描器自己去過濾。那么為了解決查詢問題，就必須加大內(nèi)存和使用固態(tài)磁盤來解決查詢速度，這就是第二難，實(shí)際上hbase類lsm樹的查詢機(jī)制復(fù)雜度遠(yuǎn)高于寫入，而且提升基礎(chǔ)資源成本改善性能并不具有普適性，這就是另一個(gè)問題了！

或許LevelDB，rocksdb，這些輕量級(jí)的kv的查詢性能比起hbase會(huì)更適合事務(wù)單元內(nèi)的高密度kv查詢，但hbase還是傾向于大吞吐kv寫入和熱點(diǎn)數(shù)據(jù)查詢用于支撐實(shí)時(shí)流處理過程的流庫連接。因此我認(rèn)為hbase要是考慮在未來支持分布式rdbms，必須得徹底升級(jí)master服務(wù)支撐region server的分布式一致性，并且實(shí)現(xiàn)跨表的ACID特性支持，最后就是region級(jí)別的讀優(yōu)化。

延伸閱讀：

二、MongoDB是什么

非關(guān)系型數(shù)據(jù)庫(nosql ),屬于文檔型數(shù)據(jù)庫。MongoDB采用類JSON的documents來存儲(chǔ)數(shù)據(jù)。數(shù)據(jù)結(jié)構(gòu)由鍵值(key=>value)對(duì)組成。

MongoDB采用動(dòng)態(tài)數(shù)據(jù)模型schema，這意味著不需要預(yù)先定義表的數(shù)據(jù)類型和字段名。當(dāng)MongoDB需要更新文檔documents的時(shí)候，可以輕松增加新的字段名或者刪除舊的字段。MongoDB讓數(shù)據(jù)結(jié)構(gòu)更加層級(jí)化，因而存儲(chǔ)數(shù)組等復(fù)雜數(shù)據(jù)結(jié)構(gòu)。 在同一個(gè)集合collection中，文檔document對(duì)字段也沒有強(qiáng)約束，因此更容易設(shè)計(jì)差異化的數(shù)據(jù)結(jié)構(gòu)。