一、为什么不用key-value型数据库实现关系型数据库

TiDB / CockroachDB 都是基于 KV 模型做的分布式关系型数据库。TiDB 实际上是构建在 TiKV + pd 这一分布式 KV 存储上的数据库。所有表都以行的形式存在 KV 数据库里。

e.g. TiDB 表 a 的某一行，主键为 b，就会变成 TiKV 里的一个 KV pair。key 为 table id + primary key, value 为这一行所有列的值。

在继续回答之前先定义一下 KV 型数据库，区分开存储引擎和基于 KV 的关系型数据库。RocksDB 是 KV 型数据库（或者说单机 KV 存储引擎）；TiDB 是基于 KV 存储引擎做的分布式关系型数据库。

至于“日常业务中的很多简单查询”是否用基于 KV 的数据库更好，可以先从存储引擎的角度看。

从存储引擎的角度来讲，不管是 MySQL InnoDB 的 B+ 树，还是基于 LSM-Tree KV 存储引擎的 MyRocks / CockroachDB / TiDB，跑一个 SELECT * WHERE pk = 1; 读的路径应该不会有太大的区别，无非是根据 sort key 定位对应的 page / block 然后把一行捞出来，所以没有好坏之分。

与此同时，如果这些“简单查询”就是直接跑在 KV 存储引擎上的（比如问题中提到的 RediSQL），只是简单地把 SQL 翻译成了 KV 操作，还需要考虑对表的操作是否有事务隔离性的要求。即使是“简单的”操作，e.g.

UPDATE x = x + 1;

也需要考虑事务的隔离性。对于 KV 存储引擎来讲，大多数引擎只提供点查、删除、scan 的接口，开发者要在上面自己实现一层事务层。特别是在分布式场景下，这个事情就有点复杂了，和分布式关系型数据库所面临的问题是一样的。

所以讲到底，如果要在 KV 引擎上实现关系型数据库，即使只支持简单的 query，也需要处理很多 KV 引擎本身没有考虑到的事情，比如事务、持久化（对于 in-memory engine 来说）等等。

延伸阅读：

二、MongoDB是什么

非关系型数据库(nosql ),属于文档型数据库。MongoDB采用类JSON的documents来存储数据。数据结构由键值(key=>value)对组成。

MongoDB采用动态数据模型schema，这意味着不需要预先定义表的数据类型和字段名。当MongoDB需要更新文档documents的时候，可以轻松增加新的字段名或者删除旧的字段。MongoDB让数据结构更加层级化，因而存储数组等复杂数据结构。 在同一个集合collection中，文档document对字段也没有强约束，因此更容易设计差异化的数据结构。