实力分析开源分布式数据库如何搞定OLTP

7月28日，以“科技，洞见未来”为主题的 QingCloud Insight 2016大会将在北京召开，连接云计算产业链上下游，展示 IT 领域最新研发成果。作为 NewSQL 技术的代表，PingCAP 联合创始人&CEO 刘奇将在本次大会上讲述开源数据库 TiDB 的设计与研发技术细节。在云和大数据时代，数据库领域发生了什么？新应用需要什么样的数据库？开发者需要哪些新技术？刘奇日前接受 CSDN 记者的专访，从 TiDB 的研发开始，就传统数据库面临的挑战，新型数据库的特性，开源模式的优势，TiDB 的研发进展，以及数据库与云计算资源更好配合的方式等问题进行深入解析。
　　
　　PingCAP联合创始人兼CEO刘奇
　　刘奇，PingCAP 联合创始人兼 CEO，先后创建了 TiDB、Codis 等知名开源项目。曾任豌豆荚、京东资深系统架构师。同时也是知名的 Go 语言专家和 Redis 专家。现从事开源的分布式 NewSQL 数据库 TiDB（受 Google F1 启发）的开发。擅长高并发、大规模、分布式数据库系统架构设计。
　　数据库领域的变化
　　CSDN：首先谈谈您在 QingCloud Insight 2016 上的分享话题。
　　刘奇：我会讲怎么去构建一个分布式数据库，主要是介绍我们是怎么实现 TiDB 的。经过大约一年半的研发，TiDB 现在已经发布了 Beta 1版本，进入一个快速迭代的周期，预期在三个月内能迭代到一个 GA 的版本。作为一个数据库产品，我们对 TiDB 进行严格的测试，以保证数据不会出问题。
　　CSDN：哪些人应该了解这个内容？
　　刘奇：DBA、系统架构师、CTO 甚至 CIO，因为他们需要了解Database 对于企业真正的价值。不同数据的重要性是不一样的，核心价值的数据永远不能丢失。比如说银行，最核心的可能就是账号、存款这些金融相关的这些数据，其次就是和业务相关的，再次就是一些日志。
　　CSDN：金融等行业核心有传统关系型数据库，也在针对不同数据尝试 NoSQL，为什么还需要 TiDB 这样的 NewSQL 技术？
　　刘奇：银行其实也面临互联网转型的压力，传统数据库经过这么多年，已经不能适应现在转型期用户数据增长的速度，也不能很好地支持跨数据中心多活——热备都是比较过时的技术。当然银行在很大程度上还要考虑风险，即使有一个新的数据库，他们也很难在短时间内将其部署到最核心的业务，但是可以先从外围开始测试，体验分布式带来的好处，支持业务快速地往前发展。
　　CSDN：不仅 TiDB，很多分布式的数据库都采用开源的模式，为什么这个领域这么喜欢开源？
　　刘奇：首先，数据库可以分为 OLAP 和 OLTP 两大类，OLAP 对于数据的安全性重视程度没有 OLTP 那么高，丢失几条数据对于用户行为分析而言关系不大。目前开源领域以 OLAP 居多，因为实现难度和风险更小，但是真正往 OLTP 上走是非常困难的。实际上，在 Google Spanner 论文出来之前，就没有真正的大规模 OLTP 分布式数据库，OLAP 的系统可以轻松扩展到两百台机器，但 OLTP 数据库能上到两百台机器是非常罕见的，以前也没有什么特别好的技术。被 Apple 收购用于提供 Apple 内部服务的 FoundationDB，也就能 Scale 到一百台左右的规模。很多同行都走了很多的弯路，Spanner 一出，架构就得跟着重新去改。
　　而使用开源数据库，无论是从被绑架的风险，还是说灵活程度，可扩展性，甚至是和其他工具的整合，都有明显的优势。
　　首先是不会被某个数据库绑架。其次，开源是大家协作的一个系统，通常你遇到问题很有可能被别人 Fix 掉了，而且你也有很多地方可以交流经验。同时，很多人会参与贡献，哪怕是一点小需求，只要用的人足够多，官方一般都会接纳——就算官方不接纳，你也可以 Fork 一些分支完成自己的需求，这是商业数据库不可能做得到。另外是和其他开源工具的整合，开源对开源一般都会很友好，比如整个阿帕奇社区几乎所有的东西都可以很好地整合，Hadoop、Spark、Flink 最终会形成一个相互依存、良性竞争的超级大的生态。
　　TiDB 的研发思路
　　CSDN：谈到 Google Spanner 的论文，TiDB 在哪些方面借鉴了它的设计，哪些方面是有独到的一些创意？
　　刘奇：TiDB 大量地借鉴了 Google 的论文，也做了很多自己的改进。比如说：
　　Google 使用的是 tech source，尽管有其他的实现，但没有一个真正受过大规模生产环境的考验。我们在协议上选择的 Raft，也是经过了非常严峻的生产环境的考验，比如 etcd 、Hashicorp 都在用 Raft，大家还有很多基于 Raft 专门造的各种轮子，同时 Raft 性能和 Paxos 差不多，但简洁性是后者所不具备的。
　　关于协议，还有 Google 内部使用了自己的 ORM，而我们兼容的是 MySQL 协议，在易用性上比 Spanner 或者说比 F1 要好很多，用户不需要重新学一套新的东西就可以直接用；我们接下来还会支持 MySQL 的 Documents store，用起来就更爽了。
　　另外在整个架构上，Google 依赖自己的 Colossus 分布式文件系统，而我们是不依赖的。如果依赖一个分布式文件系统，用户需要多部署一个新的组件，同时也会造成一定的 latency 上升，这是我们不希望看到的。
　　再一个比较重要的改进就是原子钟，这是 Spanner 最强的地方—— Google 内部有一个原子钟加 GPS 时钟，组成一套精确的时钟系统，这在外面是没有的。我们在事务模型上面使用了 Percolator，是 Google 之前发表的另一篇论文里提到的一个增量处理的事务模型，这也是外面没有原子钟的变通方案。
　　CSDN：能否解释具体是怎么实现的？
　　刘奇：按照原来的 Percolator，会有一个 Server 提供直接时钟服务，也就是单调递增的时间戳的分配，它本身是高可用的，通常会部署三到五个副本，大概每秒可以分配四百万到八百万个时间戳。从目前的需求来看，每秒四百万个时间戳是绰绰有余的，这是在没有原子钟的时候的一个替代方案。另外一个方案就是 HLC，但 HLC 如果要保证线性隔离级别，需要设置一个时钟适中的精度，但是没有云厂商明确说时钟精度一定保持在什么范围。这是一个比较大的问题，如果时钟精度超出这个范围，结果就是错的。我们不想因为时钟精度造成用户数据出错的可能，所以就选择一个更加稳定的一个方案。HLC 也是Kudu 和 CockroachDB 采用的几乎同时发表的技术极为相似的两篇论文。
　　CSDN：兼容 MySQL 的方式是业界通用的做法吗？
　　刘奇：不是，主流做法是我搞一套我自己的，让用户切进来，这对于新东西的推广的压力非常大。兼容它很重要一点是数据库的测试，我们现在测试用例都是用几百万级的，600 多万个 Tests，可以把 MySQL 的兼容，大量 Test 拿过来用来测试，如果靠人去构建这个 Test 基本上是不现实的事情。MySQL 已经是一个很好的平台，融入平台，可以让大量已有的生产力得到发挥。如果不能很好地兼容这个平台上所有的东西，反而自己去建立一个平台，周期是很吓人的。
　　CSDN：会追的最新版本的 MySQL 吗？
　　刘奇：我们现在追的是 5.6，因为 5.7 的官方也还在快速的更新，比如说5.7推出的 Documents store，现在还没有用户，我们这时候去支持它是没有太大的意义。我们做一个东西一定是满足用户需求，然后兼容协议，对用户来说迁移特别简单，就比如说现在直接测试。
　　CSDN：是否需要开发一些专用的工具来支持 MySQL 到 TiDB 的迁移？
　　刘奇：不需要其他所谓的第三方工具，直接使用任何已有的 MySQL备份、恢复工具就可以了。我们现在的测试都是直接把 MySQL 数据导出来，导入到 TiDB，再拿 TiDB 的数据导回 MySQL，完全不需要任何新的工具。绝大多数时候一行代码都不改，立刻可以获得所有的新特性和分布式的优势。
　　CSDN：传统的 DB2、Oracle 的迁移也是一样简单的吗？
　　刘奇：这个事情就比较麻烦了，因为我们并不兼容这个 Oracle，也不兼容 DB2，而且它们互相也不兼容。这时候用户如果要迁移，用户需要改它的 SQL，需要改掉存储过程，因为我们不支持存储过程、触发器这些前两代单机数据库的技术，对一个分布式系统来说，如果在这个地方写个存储过程，这个存储过程访问的数据，又跑在其他的机器上面，这个时候存储过程的理解，和用户对于前面两代的传统数据库技术的理解是不一样的，那按照它前面这个思路去写现在这个程序有可能会出现一个比较大的问题。所以传统像 DB2，Oracle 迁过来是稍微有点麻烦的，就是他们需要自己去改 SQL。
　　CSDN：对 NoSQL 端的兼容有什么样的计划？
　　刘奇：我们不考虑兼容 NoSQL（当然用户可以自己去修改兼容MongoDB 或者 HBase 的 API）。NoSQL 已经是上一代的技术，我们没有必要在上面再做太多的别的一些东西，直接跳到 NewSQL 这一代就可以了。国外有人在 PostgresSQL 上做一套 MongoDB 的兼容，我们认为没什么意义。而我们兼容 MySQL 协议，是给 MySQL 提供了很多原本不能够实现的东西，比如说异地多活，跨数据中心复制和容灾，水平伸缩。
　　CSDN：水平伸缩能够支持多大的规模？
　　刘奇：我们的设计，单个数据库支持千级别的机器，如果超过这个数量可以重新再布一个新的实例，又可以支持这种千级别的机器。但目前还没有找到这么大的业务。
　　CSDN：目前有如何商业化的考虑吗？
　　刘奇：TiDB 的核心技术是完全开源的，但我们将来会提供企业版。我们有一个 On-Premise 的版本 ，提供的一些监控和管理工具，这些工具就不需要开源了。这其实也是目前开源数据库的主流做法。比如 MongoDB，它的核心东西都是开源的，一般用户从来不用考虑付费问题，但是它会给企业用户提供一套收费的非常漂亮的管理界面，这是一个主流的收费模式。另外还可以给用户提供技术支持和维护的服务，以及咨询服务。开源不影响卖 License，我们仍然为企业提供 License 授权。
　　云计算环境的整合
　　CSDN：开源分布式数据库想要在云上做为一个服务提供给用户和开发者，最重要的工作是什么呢？
　　刘奇：对用户体验最好的，肯定是和云做深度整合，用户不需要关心新启一个机器这种细节，只要设定一个配额，容量不够的时候自动给我扩容就好了（同时发邮件通知），这样 易用性是最友好的，这在国外也比较常见，可以保证业务完全不停，国内很多上第三方市场的方式，就没有和云做深度整合，易用性相对还是弱一点。
　　CSDN：要满足异地多活等特性，TiDB 对云资源的使用上遇到过一些问题呢？
　　刘奇：异地多活，起码异地之间的 latency 不能太大，否则用户一个正常请求，尽管 TiDB 是采用 Raft 这样的多数派复制的方案，复制到多个数据中心延迟就比较大了，像 Spanner 可能在百毫秒级别的，它最夸张业务会复制五到七个副本，分布在五个不同的地区。现在国内的普遍做法是同城异地，同城机房可以保持很好的同步，因为 latency 特别小，异地的机房之间仍然保证不中断业务，但 latency 会上来。
　　CSDN：异地同步可以交给云来自动做吗？
　　刘奇：这个显然要由数据库层来做，因为只有数据库层才知道这事该怎么做，否则底下的存储层很难做出最优雅的决定，比如说没有这个数据库之前，MySQL 在云上是没有办法 scale 的。但是云可以提供很好的支撑，比如说拉专线让 latency 变小，相当于从硬件层解决问题。简单来讲，数据库可能是造车的，机房的专线就相当于一条高速公路，因为它的 latency 很小，很适合数据库做异地多活。
　　CSDN：硬件层的故障对 CAP 的影响，要通过什么方式来解决呢？
　　刘奇：我们使用 Raft 的协议，容灾的能力就是二分之 N（N 为奇数），最多不超过二分之 N 的机器挂掉时候可以正常使用，所以在云上面，如果说一个机器挂掉，对于整个系统是没有影响的，或者一个机器网络出了问题，它被隔离掉也没有影响。机制上它并不依赖与云给它提供的稳定性和安全性，这个协议本身就负责保证它的稳定性和安全性。
　　CSDN：TiDB 要部署到云上，对于下层 IaaS 的需求就是一个高速公路吗？
　　刘奇：主要就是高速公路，另外对机器或者容器的弹性支持，因为数据库扩容的前提，是新加一个机器，必须要给我提供一个 API，或者提供API 让我马上加个 Container，无所谓是 Docker 还是 Rocket。
　　CSDN：开源分布式数据库未来一定要和 Container 结合吗？
　　刘奇：结合是肯定的事情。未来分布式数据库会往多租户的方向走，但是目前对多租户还没有很好的技术支持，这时候怎么去做隔离，容器化是个很好的思路。但是分布式数据库也不是简单的容器化的问题，因为它被隔离在很多机器上面，它的配额，或者说它的请求，时时刻刻都在变，你对它的约束必须是在整个系统级别的约束，而不是单机上的约束。未来的程序一定是跑在容器里面的，但是存储可能挂在容器外面。目前我们已经初步完成了跟 Kubernetes 的整合，还在做进一步的测试。目前我们希望很好地跟 Kubernetes 或者跟 OpenStack 整合。我们有 Dockerfile，可以直接通过 Container 部署，很多热爱开源的开发者希望自己去编译，也支持直接 apt-get、RPM 来安装。
　　开发工具与难点
　　CSDN：使用 Golang 开发的是因为您擅长Go吗？
　　刘奇：我擅长 Go，也擅长 Rust，但我之前写了六七年的 C++，再之前大概写了两年的 C、一年的汇编，中间还写过大概半年的 C#，C++ 是用得最久的。但 TiDB 其实是两层，包括 SQL 层的 TiDB 和 KV 层的 TiKV，分别对应着 Google 的 F1 和 Spanner。TiDB 之所以用 Go 开发是因为开发速度快——实现 MySQL 兼容需要非常大的工作量（目前为止还没有完全实现兼容），需要选好开发语言让我们很快地适应 MySQL 的变化。另外，TiKV 是用 Rust 写的，Rust 的性能非常好，可以满足 KV 操作的需求；同时它没有 GC，可以避免了 Go 语言里面本身存在的一些问题；此外 Rust 对错误检查又严格无比，这对一个非常重视质量的项目来说非常重要，可以很好地解决了这个多线程数据竞争等问题。
　　CSDN：Go的 GC 问题如何解决呢？
　　刘奇：在压力大时候，GC 就是个问题，这需要去不断地优化。我们整个系统的实现，减少内存的分配、重用对象等常规的优化 GC 的算法都用的上。
　　CSDN：到目前为止，开发过程中最耗费精力的是哪一项工作呢？
　　刘奇：应该是测试。分布式系统的测试本身就非常困难，对数据库的测试要求就更高了，必须要非常严谨地做所有的可能性的测试，我们需要有工具不断地去模拟机器挂掉、网络断开、磁盘损坏/变慢、程序被kill等所有的故障，我们现在有 Test 不间断地杀程序，杀完之后马上检查数据有没有丢，以保证无论出现什么极端的情况，数据都是正确的、完整的，这种测试是非常重要。然后我们还同时跑着几百万个 Test，目前也是分布式在跑。我们有很多关于分布式系统的论文，但是关于分布式系统的测试的论文其实很少，高质量的就更少，Google 也没有告诉大家说 Spanner、F1 到底怎么做的 Test，外面的经验跟 Google 还是有差距的。
　　TiDB 的适用场景
　　CSDN：测试如此重要，那不同行业的数据库应用场景千差万别，我们是要把所有的方向都测试，还是说目前有些侧重的场景？
　　刘奇：首先我们能够支持传统的 sysbench 之类的常规测试。至于各种行业的不同应用类型，我们不可能完全测试到。我们这边模拟的方案，和用户那边实际报过来的 case，以及用户提供的数据，我们都会进行统一的测试。但是开源带来的好处，是用户可以下载帮我们做测试。
　　CSDN：你认为哪些场景、哪些应用应该使用 TiDB ？
　　刘奇：在数据库上遇到瓶颈的地方都可以。数据库不应该是卡住业务的瓶颈，当业务在快速发展的时候，如果这数据库遇到了性能问题、扩展性、数据保护等问题，需要多数据中心的容灾能力，这个时候可以上 TiDB。不一定是场景驱动，只要数据库真的遇到问题，就可以上一个更好的数据库。
　　CSDN：采用 TiDB 之前，应该做哪些准备工作？
　　刘奇：如果是 MySQL，那比较简单，可以拿真实数据直接去测试，可以像互联网应用常规做法，先导一部分流量进来，可以很好做一个双写，去验证这个系统，并保持这种状态持续一定的时间。然后如果不是MySQL，可能就需要先转化到 MySQL 这种语句，最好是拿自己实际业务去测试，这样发现问题也比较聚焦，不建议只是简单地 bench 一下。