为什么分布式数据库这么喜欢用kv store

虽然不论是单机数据库（MySQL、PostgreSQL等等），还是题主说到的分布式数据库（CockroachDB、TiDB），都存在KV这个抽象，但对于KV这个接口的设计，还是存在差别的。

一、为什么分布式数据库这么喜欢用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接口，bulk load不好做，并且索引本身也是多版本的
• 后面一种设计，由于存储引擎具有了schema信息，索引可以有更多的优化空间。例如索引可以做成单版本的（PostgreSQL），指向多版本的heap file，以省去多版本的开销；例如像X-Engine那样，利用LSM 的特性实现更加高效的Fast DDL

简单总结一下，虽然大部分数据库都有KV存储这个抽象，但仍然存在很大的设计空间，例如单机的KV是否需要支持事务，是否需要感知schema，是否需要暴露多版本的接口。因此，不能笼统地说分布式数据库都喜欢用KV store。

延伸阅读：

二、主要的单机存储引擎

1、哈希存储：hash的CRUD是非常快的。但缺点是不支持顺序扫描。bitcask是一个基于hash表结构的存储系统。他将写操作（包括删除标识）追加到文件尾。并定期合并新老文件&记录。

2、B树：既支持随机读取又支持范围查找的系统。查找时间复杂度为logd(n)（d为每个节点的出度）。Mysql的InnoDB的引擎和OS的文件系统使用的就是B+树。（为什么选择使用B树的变种B+树，读者有兴趣可以去探究下。提示：磁盘读取）

3、LSM树(Log Structured Merge Tree)：由B+数改进而来。其思想为：将增量写操作保存在内存中，超过阈值时刷入磁盘，从而减少随机写磁盘操作。读操作则需要合并磁盘数据和内存中的写操作。通过Memtable/SSTable实现，实现细节在此不做深入探究。比较适合写操作较多的业务场景。BigTable/HBase/Cassandra中的列簇的数据存储方式采用的即是LSM树。