一、為什么分布式數據庫這么喜歡用kv store

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

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

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

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

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

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

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

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

延伸閱讀：

二、主要的單機存儲引擎

1、哈希存儲：hash的CRUD是非常快的。但缺點是不支持順序掃描。bitcask是一個基于hash表結構的存儲系統。他將寫操作（包括刪除標識）追加到文件尾。并定期合并新老文件&記錄。

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

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