【PT 展演讲实录】TiDB：世界级开源 NewSQL 分布式关系型数据库

以下为现场演讲实录：

大家好，我是黄东旭，是 PingCAP 的联合创始人兼 CTO。我们 PingCAP 是在开源分布式领域的一个新的公司。简单自我介绍一下，我在分布式系统和互联网领域有多年工作的经验，今天我给大家带来的演讲题目是关于我们一个主要的产品——TiDB，这是一个世界级的开源 NewSQL 关系型分布式数据库。

先整体说一下我们做这件事情的背景。大家也知道关于数据库这个事情，在 08 年以前基本上是以单机型数据库为主，比如大家耳熟能详的 ***，MySQL，*** 等这样的单机数据库来支撑你的数据存储业务。但是随着互联网的蓬勃发展，接入到互联网的设备越来越多，数据量越来越大，并发处理需求越来越多，大家渐渐发现这种单机关系型数据库已经没有办法满足在互联网遇到的比如大数据存储、高并发等问题。于是，以 Google 为代表的一些互联网公司开始转向 NoSQL 这种分布式的数据库，这是一个牺牲掉关系的模型去追求可扩展性的方向。在过去的近十年来，是 NoSQL 蓬勃发展的一段时期。

但是近几年来，大家发现我们很多的业务并没有办法直接以 NoSQL 的模型来生搬硬套。很多已有的业务 ,特别是对于一些传统行业，还有在座的各位遇到的通信领域的场景来说，历史遗留下来的程序都是以关系型数据库为基础的，所以大家发现很难把这些  Old-SQL 的东西放在一个分布式的场景来使用。那我们有没有办法把单机型的 SQL 的关系模型跟 NoSQL 所带来的分布式的能力结合在一起呢？其实这就是这两年来我们整个数据库行业的一个最大的革命性方向—— NewSQL，代表产品是 Google 的Spanner/F1。Google 做了一些很前沿的工作，待会儿我会讲到。

传统的业务场景里面，在我们现在大数据的时代，有一些特殊的痛点。随着业务量越来越大，并发量越来越大，如果你是一个单机型数据库，一般来说你没有办法很优雅的解决，只能在业务层来做分库分表 或者使用中间件等折衷方案。对于一些传统的强一致性事务，比如说转账、积分等这种对强一致性 事务 要求极高的场景，只能在业务层自己来做保证，写很多代码。另外就是高可用，现在我们提到高可用，大家的第一反应是最多只能做到主从复制，如果你的主挂了，你的主从切换还是需要人工介入，比如一些金融或电信相关的场景例如计费等，就很麻烦。目前对于跨数据中心多活、跨数据中心容灾的方案来说，在已有开源实现上基本没有一个方案可以很好的去支持跨数据中心多活的架构，都是通过业务层，或者很重的 DBA 的介入来做这样的事情，但这样并不是一个真正的平滑的跨数据中心多活方案。想必在座的各位都有切身的体会。另一个是随着业务渐渐多起来之后，你的数据存储会变成一个个的数据孤岛。相当于你有很多的业务，一个业务有一套数据，这样的弊端一是资源利用率很低，二是当你需要去做一些分析的时候，就需要把分散的数据导到一个数据仓库或者分布式系统等数据分析的平台，这样实施性和可维护性都是非常差的。

有没有办法可以把我刚才提到的这些问题漂亮的解决呢？其实是有的。近两年在数据库行业有一个非常重要的新闻，也就是在 NewSQL 领域第一个在线上环境中大规模使用的方案案例，就是 Google 的 Spanner/F1，这代表一个革命性的数据库领域的突破。首先，这是一个全球级别的数据库，在 Google 内部生产环境只部署了一套 Spanner，在这套 Spanner 上大概有数十万台的物理节点，是一个超大的数据库集群。Spanner/F1 这套数据库支撑了 Google 很多最核心的业务，比如说 Google 的 Adwords，Wallet 这些非常核心的金融级业务。因为它本身是一个分布式的架构，它可以根据业务压力无限地去做一个水平扩展，或者收缩。对于 DBA 来说不会有什么分库分表，它不会把业务复杂度转嫁给开发者。开发者不用去关心底层的数据库有多大，有多少台物理机器。你可以认为底层就是一个巨大的数据库，完全没有容量的限制。

Spanner 还有一个最吸引人的革命性的点，它的上层保证了是一个完整的 SQL 支持，没有做任何妥协，也就是它支持跨行的事务。简单来说就是你如果用它来转账，不会出现由于数据存在不同的机器上，A 账户扣钱成功，B 账户没有扣钱成功这样的问题。而且它做到了任何一个数据中心宕机，底层可以完全的 Auto-Failover，上层的业务甚至是完全无感知的。这个 Failover 的过程是完全不需要人工介入的。其实国内有很多人一直在提“多活”，异地多活，很多互联网公司都在做这个方案。但是并没有哪一家公司或者哪一个方案能够像 Google 的 Spanner 方案可以完整的强一致的 Auto-Failover。

我们 PingCAP 在做的 TiDB，首先其实是在做 Google 的 Spanner/F1 的一个开源的实现。Google 的 Spanner/F1 是一个比较前沿的东西，它背后的理论基础是大概 2012 年开始 Google 对 Spanner/F1 系统描述的几篇论文。同时我们整体放弃了传统的主从复制的模型，使用了在 2014 年 Stanford 的一个博士发表的一个关于分布式选举的论文叫做 Raft。第三，我们是一个完全兼容 SQL 的一个 Database，对外暴露的是 MySQL 的网络协议和语法，你的业务基本不用做任何的修改，也不用把你的业务切换到一个 NoSQL 这样的东西上，不会把复杂度转嫁给你的业务层。所以我认为一个 NewSQL 必须支持这几个核心的特性，否则不能称之为 NewSQL。

为什么我们是真正的 NewSQL？一是我们有水平扩展，而且在水平扩展的过程中是不会将事务和强一致性做任何妥协的，是保证业务层透明的强一致的支持跨行事务的水平扩展。第二是我们能做到跨数据中心的多活，任何一个数据中心宕机，上层的业务是没有感知而且整个集群可以自动的做数据恢复和高可用，不需要任何的人工介入。第三，我们的数据库一定是面向云的架构去做设计的，不会出现一个个数据孤岛的这种状态，我们相当于是一个整体的数据库的解决方案。

另外，TiDB 是目前来说最前沿的技术领域创新项目，在 GitHub 上开源，到现在为止一年时间已经有 4700 多的 Star。TiDB 和 TiKV 两个项目的加起来大概有近 6000 的 Star 数。在这个项目里面和我们一起合作的公司包括 Facebook 和 CoreOS 都是一些耳熟能详的硅谷技术公司，在国内也有包括京东及***在内的公司的 contributor 在项目中给我们贡献代码。

刚刚我这边也说了我们底层的存储引擎 TiKV，放弃了传统的主从复制的模型，而是通过 Raft 这个强一致性算法。这个算法有一个官方的组织，在官方的排行榜里我们是排在全球第三位的实现。另外我们的底层是用 Rust 的语言来开发的，在 Rust 社区里，我们是最大的开源存储项目。现在我们在国际上的影响力也非常大，在上半年，我们受邀出席香港的开源年会（HKOSC 2016）做了报告，下个月，我们也会应大会方邀请到 PerconaEurope Live 2016 去做演讲。

我们来聊聊简单的 TiDB 的使用场景。首先，如果你在用关系型数据库，比如 MySQL 比如 *** 这样的单机关系型 SQL 的数据，当你有水平扩展的需求，当你的数据量比较大已经超出了单机的限制，比如说并发量单机已经扛不住了，但是同时你又不想在业务层做很复杂的分库分表，这时候你可以使用 TiDB。

第二，就是你的数据极端重要，不能容忍任何的数据丢失，不能容忍任何的宕机的时间，这时候你还需要跨数据中心的多活和高可用的话，TiDB 是你唯一的选择。

第三种，你需要对你整个业务做云上的改造，但却还在使用单机数据库的话，它一定会成为你整个架构的瓶颈，这时候你需要 TiDB 去帮你解决在云上的数据存储方案。

所以我们来对比一下，如果你用 TiDB 这样的 NewSQL 与你用传统的 DB Sharding 的模式，通过对业务的开发工作量的对比，我们能直观的感受到 TiDB 为什么是一个更新的架构。

比如说你在用传统的 DB Sharding 的时候，在项目的设计之初，你需要做分库分表、需要做中间件的选型、需要做主备的设计，可能是数以月计的，而且你还要有很强的架构能力去帮实现这事情。

第二在你的开发阶段，如果你是用传统的单机型数据库或者直接去做业务层的分库分表的话，很多业务的跨库、跨表的事务的查询是没有办法直接在数据库做的，需要业务层对连表查询去做保证，但这个程序的复杂度是非常高的，工作量至少要以月计算的。

另外当你的数据量大到一定程度，你需要做一次扩容，在传统的 DB Sharding 方案上，基本是没有办法去搞定的，复杂度会随着节点数的增加形成指数级的提升。

但是，我们可以看到在 TiDB 这样的 NewSQL 的产品之上，基本上刚刚说的这几点的工作量都是可以忽略不计的，因为它是一个完全透明的分布式关系型数据库，容量不够了，我只需要简单的加机器就行了，我的 transaction、我的 SQL 都是完全兼容传统的单机型的 SQL 的。

关于今天的主题，我们是想强调一下安全和高可用。首先我们可以发现，目前来说并没有一个很好的方式去实现跨数据中心的数据级的高可用的安全保证。比如说银行需要有两地三中心的这种场景，一般来说都会选择前两种方案：一个是 *** 的小型机，或者传统的硬件或者高端存储这种硬件复制的方案，缺点一是价格昂贵，另外，备份是一个冷备，就是当你的主生产中心故障时，还是需要人工手动去切换业务；第二种是 *** ADG，但是 ADG 的方案和用传统的 *** 的问题也是一样的，一是需要去额外购买 license，第二是并没有办法做到真正意义上的多活，他的备机也是一个 stand by，仍然在故障的时候没有办法做到秒级的 RTO，还是需要人工的介入，人工去确认数据没有问题，人工去把备机切换上来，这都是故障的隐患。

第三就是 MySQL，这个就不用说了，可以说这种互联网的开源关系型数据库，没有原生的安全的同步解决方案。

我们其实放弃了刚刚我说的这些所有的主从复制的方案，我们用了一个更先进的一致性算法，去保证所有的数据中心融为一个整体，达到了百分百的同步，真正做到了异地多活。我们的故障恢复时间是秒级，然后恢复出来的数据不会跟之前的数据有任何的不一致，就是说不会有任何的丢失，也就是 RPO是 0。

最后我想说一下，为什么我们把 TiDB 开源。因为我们认为开源是基础软件唯一的正确模式，或者说基础软件如果不开源，未来一点机会都不会有的。这个道理很简单，比如说在座的各位如果你们去做技术选型或者做一个新的业务的时候，如果一个开源软件的质量和闭源软件的质量是一样的，你是会选择开源软件还是闭源软件？答案显而易见。

过去这么多年，我们都能有感觉，就是我们的业务并不想被任何一个专有的厂商绑架。而且大家也能看到现在各种各样的开源软件已经逐渐形成了一个生态。比如我的缓存可以用 Redis，我的数据库可以用 MySQL、PG，我的分析引擎可以用 Spark、Hive 这样的 OLAP 数据库 ，他们在渐渐组成一个非常大的生态，这不是任何一个闭源软件公司能够给出来的一个完整解决方案。所以我觉得未来，无论是数据库也好，分析引擎也好，拥抱开源才是一个正确的模式。

另外，开源并不是一个严格意义上的商业模式，它是一个更好的软件开发的方式。首先，它的成本是会比用闭源软件更低；其次，它的扩展性会更强；然后，它的代码是有无数双眼睛在盯着，很难有 Bug 在后面隐藏，所以大家是在互相协作把这个软件做到最好的；第四就是，开源软件可以复用很多现有的社区的力量，能带来 1+1 大于 2 的效益。

然后开源是一种更好的软件的分发模式。它的安全性更高，然后门槛会更低。比如说我有一个场景，我没有什么方案，如果这时候你用闭源的软件，你要去发现这个软件，还要找这个公司拿到测试软件包，再去走 POC，流程非常长。但如果你是用开源的软件，在使用的时候很简单，直接把代码拿过来编译去验证，甚至针对你的业务去做定制。而且如果这个定制是大家都广泛需求的 patch，你可以回馈给开源社区。

因此，开源软件会随着社区的不断进化和迭代，质量会越来越好，而且社区会越来越庞大。所以我们认为对于基础软件来说，开源是唯一的未来。

这是我们的项目地址，如果大家感兴趣的话，可以去 GitHub 上试用。我们公司的名字叫 PingCAP，这是我们的微信二维码，有兴趣大家可以加一下。

以上，就是我今天要讲的全部内容，感谢大家。

分布式 NewSQL 数据库

www.pingcap.com

微信ID：pingcap

长按左侧二维码关注