一、為什么分布式數(shù)據(jù)庫這么喜歡用kv store

雖然不論是單機數(shù)據(jù)庫（MySQL、PostgreSQL等等），還是題主說到的分布式數(shù)據(jù)庫（CockroachDB、TiDB），都存在KV這個抽象，但對于KV這個接口的設(shè)計，還是存在差別的。

數(shù)據(jù)庫通常會有這么幾個模塊，KV存儲、事務(wù)、索引，這三者之間的關(guān)系看起來涇渭分明，但實際上交織耦合，其中存在很多設(shè)計點。

名列前茅種設(shè)計是目前share-nothing分布式數(shù)據(jù)庫用的比較多的：基于單機KV存儲實現(xiàn)分布式KV，再基于分布式KV實現(xiàn)事務(wù)，在distributed transactional key-value store的基礎(chǔ)上再實現(xiàn)global index，以及查詢引擎。在這種設(shè)計下，單機的KV存儲甚至不需要支持事務(wù)，因為完全可以基于這個KV實現(xiàn)分布式事務(wù)。典型代表是TiDB。

這種設(shè)計的好處不再贅述，看一下局限性：分層太過清晰，想打通多個層次的時候反而比較復(fù)雜。例如分布式事務(wù)，是不是可以和Consensus Protocol融合，實現(xiàn)安全的MVCC Follower Read？是不是可以借助單機引擎的事務(wù)，來優(yōu)化單個region內(nèi)的事務(wù)避免分布式事務(wù)的開銷？

所以第二種設(shè)計，保留單機事務(wù)的概念，把單機事務(wù)當(dāng)做common case，而分布式事務(wù)只是錦上添花。奠定了這么一個基本概念之后，通常索引也會優(yōu)先做成單機的，全局索引的優(yōu)先級降低甚至不做。在這種設(shè)計下，單機的KV存儲，事實上就需要支持事務(wù)，甚至，為了在此基礎(chǔ)上做分布式事務(wù)，還需要提供一些額外的接口，例如point-in-time snapshot read。典型代表是MongoDB。

由于具有了原生的單機事務(wù)，因此在common case下會很高效，可以當(dāng)單機數(shù)據(jù)庫來用。但其痛點也隨之產(chǎn)生：如何基于單機事務(wù)做分布式事務(wù)，兩階段提交怎么做，事務(wù)隔離怎么做，多版本讀怎么做？并且，這些功能往往會耦合于單機的事務(wù)引擎，可想而知其復(fù)雜度。

如果單獨考慮第二種設(shè)計中的索引實現(xiàn)，又會產(chǎn)生多種的KV接口設(shè)計。索引是基于KV做，還是下沉到KV中？

簡單總結(jié)一下，雖然大部分?jǐn)?shù)據(jù)庫都有KV存儲這個抽象，但仍然存在很大的設(shè)計空間，例如單機的KV是否需要支持事務(wù)，是否需要感知schema，是否需要暴露多版本的接口。因此，不能籠統(tǒng)地說分布式數(shù)據(jù)庫都喜歡用KV store。

延伸閱讀：

二、主要的單機存儲引擎

1、哈希存儲：hash的CRUD是非?？斓?。但缺點是不支持順序掃描。bitcask是一個基于hash表結(jié)構(gòu)的存儲系統(tǒng)。他將寫操作（包括刪除標(biāo)識）追加到文件尾。并定期合并新老文件&記錄。

2、B樹：既支持隨機讀取又支持范圍查找的系統(tǒng)。查找時間復(fù)雜度為logd(n)（d為每個節(jié)點的出度）。Mysql的InnoDB的引擎和OS的文件系統(tǒng)使用的就是B+樹。（為什么選擇使用B樹的變種B+樹，讀者有興趣可以去探究下。提示：磁盤讀取）

3、LSM樹(Log Structured Merge Tree)：由B+數(shù)改進而來。其思想為：將增量寫操作保存在內(nèi)存中，超過閾值時刷入磁盤，從而減少隨機寫磁盤操作。讀操作則需要合并磁盤數(shù)據(jù)和內(nèi)存中的寫操作。通過Memtable/SSTable實現(xiàn)，實現(xiàn)細(xì)節(jié)在此不做深入探究。比較適合寫操作較多的業(yè)務(wù)場景。BigTable/HBase/Cassandra中的列簇的數(shù)據(jù)存儲方式采用的即是LSM樹。