TiDB 是一个位于北京的创业公司 PingCAP 的产品，它是一个新型的数据库。PingCAP 成立于 2015 年。联合创始人是刘奇、黄东旭和崔秋。在 2017 年的时候，他们完成了 1500 万美元的融资。今天我们的故事主角就是这个国产数据库和它背后的公司。

说起数据库产业，其中的经典是关系数据库。这一类要么是外国大公司的商业数据库，其代表是 Oracle 数据库，IBM 的 DB2，以及微软的 SQL Server；要么就是开源的数据库，这类以 MySQL 和 PostgreSQL 为代表。

进入新世纪后，随着大数据相关技术的出现，又有了一些 NoSQL 的产品。

在数据库的发展上，关系数据库好用，但是扩展性差，对于大数据场景不好；NoSQL 产品可以支持大量的数据和大规模的访问，但是可用性却非常差，对产品开发来说，使用时要注意的事情太多。

那么说，有没有一种产品兼有关系型数据库和 NoSQL 的优点呢？进入到 2012 年以后，大数据技术奠基者谷歌发表了一系列新论文，主要讲述了它们新开发的一个叫做 Spanner 的数据库。这种数据库同时具备了关系数据库和 NoSQL 的优点。所以通常我们又把这个类型的数据库称为 NewSQL。

TiDB 就是这样一款数据库，它的基本理念就是基于 NewSQL 的技术，这个项目的名字 TiDB，也包含了一定的含义。引用联合创始人黄东旭的说法，Ti 是金属元素钛，这是一种非常坚硬的金属，以此来象征他们的数据库牢不可摧。

它背后的公司，则是给自己取名叫做 PingCAP。对于做系统的人，肯定能理解这是一个雄心壮志的公司。这个名字的本身包含了两层意思，“Ping” + “CAP 理论”。

Ping 是 TCP/IP 里面的“ping”命令的意思。它的本意是用于查看一个 IP 地址是不是可以连得上，用在这个公司的名字上是用来表达“连接”的意思。

再来介绍一下 CAP 理论，CAP 理论主张任何基于网络的数据共享系统，最多只能拥有以下三条中的两条：

  • 数据一致性（C），等同于所有节点访问同一份最新的数据副本；
  • 对数据更新具备高可用性（A）；
  • 分区容错性（P）。

所以说，CAP 理论主要是说在一个系统中，C、A、P 里只能满足三条的两条。而这个公司的名字 PingCAP 就是希望可以连接 CAP，同时满足三者的条件。

那么为什么我们需要连接 CAP 呢？这是因为 CAP 理论就是所谓的三者选两个，系统在任何时候都是只选特定的两个。

当网络表现良好的时候，P 不存在，所以 C 和 A 是可以兼得的。而网络一旦出问题，C 和 A 之间选择哪个，其实是传统关系数据库和 NoSQL 的区别。

但是，NewSQL 里因为它良好的实现，可以更大限度减少 P 的出现，从而保证系统在绝大部分时候都满足 C 和 A，但是有能力实现一个系统保证绝大部分情况下 P 不会出现，是一件不容易的事情。

总之，无论从公司的名字，产品的名字，还有选择创业的方向，都证明了一个雄心勃勃的公司，正在做一款非常有难度的产品。

PingCAP 刚成立的时候，TiDB 的项目就已经立项了。但是要从头到尾做一款数据库产品有两方面的问题。一方面是技术上的问题，这个只有顶尖人才才可能解决；另外一方面是商业上的问题，现在市场上如此多的数据库，如何让大家接受一款新的数据库本身才是个问题。

PingCAP 做的第一个决定是，它们的产品会和市面上最流行的开源数据库 MySQL 保持 100% 的兼容。这样的好处是，只要是原来使用 MySQL 的客户，都可以无缝地切换过来；而原来 MySQL 的社区里面已有的资源，包括各种工具和各种测试实例也都可以直接拿过来用。

当然这样做也不是没有代价的。一款产品要和另外一款产品等价，其实也就意味着需要对另外一款产品的各种行为都有深刻的研究。这就意味着开发难度绝对不是从头建一个产品可比的。

PingCAP 在这里选择了一个非常聪明的做法。他们的开发是从上面往下走的，第一件事情是先把 SQL 层相关的东西做出来。这样的好处是在一开始就可以检测出语言级别上是不是会有不一致的地方。

PingCAP 的另外一个非常聪明的地方是，他们是很有底层软件的开发经验的。在写 SQL 层的时候，他们也把网上有关 MySQL 的测试都扒到自己的实验环境里来。因为一个底层软件的开发是否成功，很大程度上取决于测试做得有多好。

这里我们需要解释一下，底层软件本身是提供给客户用的。所以这类产品除了性能要求以外，还有稳定性的要求，而测试这类产品则需要构建不同的应用环境才可以。

如果说一切从头而来的话，整个过程会非常不容易。PingCAP 选择了和 MySQL 100% 兼容，那么他们就可以用 MySQL 社区里已经发展了 10 多年的测试，完全不需要从头写起。

PingCAP 在开发完上层的 MySQL 层以后，就进入到下层的存储层。这里他们决定学习谷歌的 Spanner，做一个体量无限大的 MySQL。

从技术上来讲，这就需要做到自动分区，而这在工业界里是非常难的一个东西。通常来说实现的方式不是 Paxos 就是 Raft，前者在谷歌的实现已经证明是非常复杂，后者还是 2014 年才出现的新方案。在全世界，真正实现了这种高可用性的公司并不多。

在上述的基础上，他们还是需要一个底层的基础存储结构。我有幸和黄东旭吃过一顿饭。聊到这方面的时候他说过，他们的选择就是拥抱开源社区了。毕竟很多东西开源社区里有非常丰富的资源。

这样一来，PingCAP 和开源社区的一些项目一起，就渐渐地把这个叫做 TiDB 的数据库搭起来了。

不过，在搭起来以后，PingCAP 面临着一个非常实际的问题：用户是不是愿意把系统替换掉。用户很多时候是愿意在实验环境下尝试一下新东西，却不代表他们有这个胆量在生产实践里就能直接替换。因为数据库如果出了问题，导致数据错误或者丢失，很多时候是灾难性的，损失无法估量。

好在 MySQL 早就实现了主从备份，主服务器用于接受写和读的操作，而从服务器则在背后同步。PingCAP 实现了 TiDB 和 MySQL 的备份通讯协议，所以 TiDB 可以作为 MySQL 的主从备份服务器里的从备份服务器，部署到生产实践的应用里去。

这样的好处是，用户只是增加了一个“从”的备份，接下来就可以直接去查询这个“从”的数据库。

用户可以将 TiDB 作为从数据库与 MySQL 作为从数据库进行比较，看看两种情况下的查询结果是否一致，并且可以同时比较两种情况下的性能差异。通过这种比较，用户可以确定 TiDB 作为 MySQL 的替代品，是不是从正确性到性能上都没有问题。

如果在从数据库的比较中，先确定了 TiDB 没有正确性问题，又确定 TiDB 的性能好于 MySQL，那么它替换主 MySQL 数据库也就成为可能了。

通过这样的一种方式，TiDB 很顺利地就打入了很多用户的市场。而且事实证明 TiDB 有良好的扩展性，对查询的速度也快很多。这样慢慢的，公司也就打开了局面。

时至今日，TiDB 才成立两年，但是它们的产品已经小试牛刀了。公司在产品的商业策略和技术实现上都表现出了非常优异的表现，所以我们完全有理由相信，在不远的将来，这个公司可以带给我们一款底层基础数据库的利器，这也是我们中国人在基础架构领域取得的一个巨大的成就。