要明确的是，FoundationDB和TiKV是一个层次的东西，都是一个支持分布式事务ACID的ordered KV map。TiKV和FoundationDB都支持，TiKV依赖PD来提供事务版本服务，FoundationDB依赖master提供，这点差不多，不同的是TiKV在事务开始的时候需要问PD拿事务开始版本。
一、TiDB和FoundationDB各有什么优劣
要明确的是，FoundationDB和TiKV是一个层次的东西，都是一个支持分布式事务ACID的ordered KV map。
接下来从原理上看看有何不同。
外部一致性：TiKV和FoundationDB都支持，TiKV依赖PD来提供事务版本服务，FoundationDB依赖master提供，这点差不多，不同的是TiKV在事务开始的时候需要问PD拿事务开始版本，而FoundationDB是从一个proxy拿，而这个proxy需要问其他的所有的proxies拿commit versions，然后取一个最大的给客户端。
分布式事务：TiKV用的是和percolator一样的方法，检测冲突是在commit的时候进行，和FoundationDB一样，都是乐观的并发控制协议，原理都是看一个事务修改的数据是否在提交前被另外一个事务动过，如果是就回滚retry。FoundationDB在2PC时的容错怎么做的，没找到相关文档，percolator论文中说的很清楚，略。
事务冲突检测：TiKV冲突检测在各个TiKV节点上，FoundationDB拎了一个单独的叫做resolver的组件出来做冲突检测，这个组件可以有多个，组件会把最近5s的已经提交的写的key放在内存中，这也是known limitations中一个事务中最大只支持5s的原因之一。
隔离级别：都是SSI，基本就是拿一个快照，然后事务内的写自己能读到(不确定TiKV是SI还是SSI)。
副本复制协议：TiKV用raft，FoundationDB文档中没看到提到这块。
架构：都是shared nothing，TiKV单机引擎rocksdb，核心数据结构skiplist，FoundationDB单机基于磁盘的B-Tree。两者都强调分层，下面是存储，上面是接口层，TiDB是TiKV的SQL接口层，FoundationDB core就是下面的存储层。稍一点不同的是，因为TiKV本质上还是为TiDB服务的，所以加了一些接口专门给TiDB用，主要是为了计算下推。
延伸阅读：
二、TiDb简介
TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的优异特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点：
