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

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

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

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

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

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

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

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

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

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

延伸閱讀：

二、主要的單機(jī)存儲(chǔ)引擎

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

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

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