【BDTC 2018】PingCAP申砾：做一个真正通用的数据库产品

戳蓝字“CSDN云计算”关注我们哦！

2018年12月6-8日，由中国计算机学会（CCF）主办，CCF大数据专家委员会承办，中国科学院计算技术研究所、中科天玑数据科技股份有限公司与CSDN共同协办，聚焦于大数据技术如何更好的服务于实体经济，关注热门技术在行业中的实践和应用的2018中国大数据技术大会（BDTC 2018）在北京新云南皇冠假日酒店隆重召开。

在此次大会的数据库论坛上，PingCAP工程副总裁、TiDB Tech Lead申砾发表了“TiDB架构解析与实践”的演讲，介绍了分布式关系型数据库的发展及现状，并详细解析了TiDB的架构及其在实际业务中的应用，在会议间隙，CSDN记者有幸对申砾进行了专访，并就分布式关系型数据库进行了深入的交流和探讨。

CSDN：作为分布式关系型数据库的TiDB与其他分布式关系型数据库有哪些不同？

申砾：首先，在分布式关系型数据库方面有两类思路，一种思路称之为Share  Nothing，另一种思路称之为Share  Everything，Share Everything的特点是采用共享存储的架构，例如AWS的Aurora以及阿里巴巴的PolarDB就属于Share Everything，它们的设计思路就是通过共享存储方案在不同节点之间共享数据，来解决数据库的扩展问题，并一般采用一个节点写入，多个节点读取的方式。这种架构的优点在于，第一，可以利用现有的数据库内核，例如MySQL和PG，直接提供非常好的兼容性，不需要自己去实现协议层和计算层。另一方面，它们的底层存储确实可以实现一定程度的扩展，比如Aurora能够扩展到64TB这样一个规模，PolarDB也能扩展到百TB，这是它们非常大的优势。但这种架构其实也有一些劣势，比如说Aurora，现在的写入是单点，也在尝试做Multi-Master的写，但还没发布，这里会有很多一致性的问题需要去处理。另一方面，当数据规模在几十G或者几百G的时候，Aurora缓存的命中率很高，但是当数据规模达到几十T，甚至上百T的时候，下层的存储，包括缓存、内存等其他资源将会跟不上，吞吐可能达不到那么高，因为它的写入还是单点，虽然计算可以扩展，但是由于写入不能扩展。同时又很难突破MySQL和PG自身的限制，比如说MySQL对分析类型的查询就处理的不是很好，很多复杂查询跑的很慢或者是无法运行。因此，在享用它们的优点的同时，也要承受它的缺陷，或者是自己去投人力做改进，比如现在Aurora也在做并行算子，包括并行扫表，并行读索引等，就是因为原有的MySQL 内核无法满足这样的需求。

另一类思路Share  Nothing的代表产品就是谷歌的Spanner，TiKV其实就是Spanner的一个开源实现。实际上，Spanner现在也在慢慢的演变成一个SQL数据库，这一点可以在Google Sigmod 17 中的论文《Spanner: Becoming a SQL System》看到。这种架构的好处在于，可以非常容易的扩展，甚至可以认为是无限的扩展。因为这种架构可以自己解决数据调度问题。TiDB与Spanner的架构或者说解决问题的目的很相似，但是会有些不同。比如说我们是开源且面向通用的场景、通用的硬件、通用的机房情况的，而Spanner需要有专用的机房、硬件时钟和较好的带宽保证。但我们想处理的是一个普遍场景的问题，需要能够让所有的公司都有机会使用类似Spanner架构的水平扩展的数据库方案，而不需有专门的基础设施。其次我们首先希望能够做好一个数据中心之内的解决方案，因为对于大多数用户来说，一个单数据中心内的分布式数据库已经能够解决很多的问题，当然我们也提供了一些方案，能够去做跨机房的部署，这时候需要和业务去做比较深入的沟通，看如何能够让数据库的跨机房更好用，一起来配合业务解决跨机房高可用的需求。

至于技术细节方面和Spanner的不同，一个比较显著地是 TiDB更加通用，比如Spanner直到最近才支持DML写入，它的读可以通过SQL，它的写只能通过交换接口。对于我们来说就不可能这样去做，因为用户是用SQL写入数据，特别是在国内MySQL用户非常多，我们兼容MySQL协议这样的功能，就是希望让大多数用户能够更好的使用TiDB，降低业务迁移的成本，而不是通过一个专用的协议去写入数据。第二，我们是开源，对所有用户都是透明的，所有用户都能看到产品的样子，因此，能够非常放心的使用，甚至有问题他们也可以自己来解决。这种开源路线，同时也能够帮助我们极大的推进产品的成熟。

CSDN：您认为TiDB的最大优点是什么？为什么会受到那么多IT技术人员的青睐？比如相比同样开源的MongoDB？

申砾：一个事实是，关系型数据库的需求要远大于文档型数据库的需求，不管从技术角度，还是商业角度来讲，两者都不是一个体量，大家可以看到MongoDB和Oracle，完全不是一个市值。一方面，关系型数据库或者分布式关系型数据库的需求，一定远大于分布式文档数据库的需求，特别是在一些核心的应用上，比如说在银行交易系统、保险证券这种核心系统中，肯定是关系型数据库。另一方面，TiDB的优势在于，第一，我们在设计之初就很好的抓住了用户、市场和技术需求的痛点，比如TiDB的四个特点，水平扩展、高可用、事务、SQL都抓住了用户的需求和痛点，现在MongoDB的最新版本也提供了事务支持，因为它意识到想进入更严肃的应用场景、更核心的业务系统一定要有事务支持，没有事务的支持，就只能应用在小规模的应用场景中。第二，是TiDB对SQL的支持，现在很多数据库都开始支持SQL，包括大家都做了很多SQL On Database这样的方案，甚至Kafka都开始支持SQL，通过SQL这样一个标准接口来提供服务是更优雅、更通用，也是更容易被用户所接受的。比如，MySQL的用户，就可以在不换代码，不换Driver，不换关键工具，不换使用习惯的情况下，直接迁移到TiDB上来。而如果想迁移到MongoDB或者其他系统上，就需要去写很多代码去做变更。当然MongoDB也有很多优点，比如文档的操作非常方便，而现在我们已经开始支持JSON，下一步会完善这方面的支持，包括在JSON中去建索引，让用户能够在一个数据库中，除了关系型模型以外，也可以用一些文档的使用方式来操作数据库。

CSDN：TiDB非常适合于OLTP和OLAP这两种应用场景，为什么当初TiDB要聚焦在这两种应用场景之上？

申砾：其实在最开始的时候，我们最想解决的就是一个OLTP的问题，因为OLTP是上游，它是最关键、最核心、最高价值的一个地方，我们想到的就是如何让用户可以更方便的扩展，解决交易类型数据业务的水平扩展问题。一开始我们希望用MySQL集群，MySQL单机，甚至是其他数据库以解决单机不能扩展的问题。但后来随着我们不断去演进技术以及用户的需求，我们渐渐发现，用户其实除了交易类型的需求之外，还有一部分分析型场景的需求。在我们最开始的几个商业客户中，就有一家是用TiDB做分析，而不是做交易，它是一个广告点击分析系统，通过TiDB去汇总数据做报表，观察点击效果。这家客户以前使用的是MySQL面临的困难是，第一，数据存不下来，第二，MySQL做分析很吃力。而使用TiDB，一方面数据能够扩展，另一方面，分析能力也获得了增强。我们发现了这样一个场景，因此就不断去加强TiDB的分析能力。为此，去年我们把优化器进行了重构，使得TiDB的分析能力得到了极大的增强。同时，从TiDB的1.0到2.0版，我们在TP的稳定性和正确性上，做了非常多的测试，包括验证、Chaos、混淆测试等去提升稳定性。另一方面，在TPC-H这个比较标准的Benchmark上，我们的1.0到2.0版本有了质的飞跃，包括所有的查询都有了数量级的提升，还有一些查询以前跑不出结果，现在已经可以跑出结果。而从2.0到最新发布的2.1，我们在TPC-H上又发了Benchmark，以前运行很慢的几个SQL现在能够运行的很快，我们后面还会再持续优化它，包括引入更多的Benchmark，比如说TPC-DS这样的Benchmark。其实，我们的数据库是希望解决TP和AP混合场景的需求。刚才提到，我们的产品需求有些是用户挖掘出的，比如在一个银行的核心交易系统里面，用户既用TiDB来处理在线交易，又用它来算报表，这就是一个混合场景，这些问题如果使用Oracle，可能需要把数据同步出来去其他地方汇总报表。这样的话，实时性，方便性就会差很多。而在这些方面，我们也在持续加强，希望能够真正做出一个HTAP实时数据处理平台。

CSDN：请您简单的介绍一下TiDB的架构，总结一下它的亮点。

申砾：从大体上说，可以认为TiDB有两个比较重要的特点，第一，TiDB是完全由我们自主研发的产品，因此，我们可以很容易的去修改和改进，但如果是使用基于其他开源项目的产品，如果用户没有很强的技术实力，将很难做这样的事。第二，得益于开源的运作方式，用户会在很多的应用场景中使用我们的产品，也能够给我们反馈很多非常好的问题，这时候，我们就可以收集很多应用场景，有的放矢的去做针对性的优化和调优，从而更好的支撑大多数用户的使用。在具体技术方面，TP方面我们会加强，比如会提供Plan Cache这样一个比较好的特性、优化器的改进以及能够在尽可能短的时间内，找到最好的一个开源计划，保持其稳定及动态的更新，包括怎么维持它的稳定，怎么使用一些启发式的规则，保证其能够在Cost-based Optimizer这个框架内，不受过期的统一性影响，依然能够找到最好的产品计划，还包括整个从TiDB  SQL层到存储层优化的打通，从上到下的联动和优化，这是TP方面优化的一些思路。另一方面，在AP方面，我们做了优化器的改进，把优化器整个推倒重写，做了一个纯基于代价的产品模型，能够处理很多复杂的查询，我们有HashJoin，IndexJoin以及Sort Merge Join三种Join算子，而MySQL只有一种Join算子，我们还能够根据代价去自动选择Join算法，包括对关联字产品的优化，对OuterJoin的消除等非常多的优化手段，可以看到我们的优化器现在是一个演进非常快也非常强大的优化器。

另一方面，是执行引擎的优化，我们在传统的行处理模型基础上，做了一次Batch加向量化的优化，这样优化器就可以感知到用户可能是要处理大量数据，这时，就可以并行的一次处理一批数据，而不是一行行处理。我们还可以从一个算子将一批数据交给上一个算子，这就减少了函数的开销。另外，在P4之间，我们是用一种列存的方式在内存中进行数据表示，一方面能够加速并减少内存的开销。另一方面，可以在此基础之上做向量化，就是可以一次处理一列数据。这样也就能够加速整个数据的处理过程，减少调用开销。而且我们很多算子都是并行算子，包括扫表、扫数据、扫索引、做Join、做聚合，包括做投影操作都是并行算子，这样一个比较智能的优化器，加上高效，强大的执行引擎，共同提升了整个分析的性能。目前，我们也在去做优化器执行引擎的的下一步改进，希望真正能够处理任意场景的查询。现在，有些用户已经在TiDB中运行几百行的SQL，我们希望以后这种查询也能够更加轻松，不需做任何改动就能够得到很好的处理。同时，在上百TB的数据里面做分析时，我们采用的包括行列缓存，冷热数据分离这样一些策略，将能够极大加速分析的性能。我们的计算存储架构，也能够很方便的将存储引擎、计算引擎分别做优化，甚至可以多套存储和计算引擎混布在一个集群当中，共同提供服务。系统可以智能的将不同的数据处理请求或者一个请求内的不同任务去分发给不同的存储或者计算引擎处理，从而让TiDB为用户提供了一个真正的实时数据处理平台。用户不需要再关心数据怎么去处理，只需要通过接口转载数据就可以了。

CSDN：TiDB被称为是云原生的数据库，您对云原生数据库是怎么看待的？

申砾：关于云原生，我觉得这个概念可以这样理解，就是应该能够非常好、非常容易、非常高效的与云结合。另一方面，用户需要的可能不止一套数据库，也许每个业务都需要一套数据库，并需要做业务上的隔离。这在单机数据库时代，虽然管理起来也相对复杂，但实际上并没有那么困难。但对于一个分布式数据库来说，管理多套分布式集群，开销还是非常大的，我们也希望能够借助于云，降低用户使用和管理多套数据库的成本，一方面我们开发了TiDB Operator，这款帮助K8S来管理和调度数据库集群的组件，另一方面，也通过云平台，让用户能够非常简单的创建或者销毁多套实例，而无需管理员的参与。同时，也希望能够借助云的环境，一方面简化用户的使用成本，另一方面也简化我们自己的成本。云能够提供一个很好的底层资源的管理和调度的手段，而且云是未来的趋势，不管是在国内，还是在国外，很多用户都希望数据库能够有云上的服务，我们马上会在AWS上提供服务，让用户通过简单的几下点击就能创建一个数据库集群。

CSDN：TiDB为什么要保持开源？您觉得开源对于TiDB的发展起到了什么样的作用？

申砾：分两方面谈，一方面是技术，一方面是商业。因为开源是一个软件分发和协作的一个方式，从技术上讲，我认为做基础架构，特别是数据库这样非常关键的底层技术软件，包括操作系统，编译器等，开源可能是唯一正确的手段，因为开源一方面能够让产品接受用户的检验，督促你去把产品做得更好，帮助你发现系统中的缺陷，找到多样的应用场景，极大地加速软件产品的成熟。另一方面，也能从开源软件获得了很多帮助，包括很多社区的会员会帮助我们检验、设计、甚至重写代码。事实上，我们公司只有大概一百人左右，而我们的社区贡献者有几百人之多。可以看到，许多知名的基础组件都是通过开源才获得了如此广泛的传播，包括Hadoop、Linux，如果没有开源，它们是不可能做起来的。开源能够极大的加速基础组件的成熟和开发速度，不开源，没有足够数量的用户使用你的产品，那么，很多用户就不敢去使用产你的产品。开源实际上相当于产品的一种可信性证明。从商业方面谈，开源也对我们有很大的促进，因为通过开源，软件的分发成本，获客成本都会变得非常低，通过开源社区，会获得很多关注，很多人也会使用我们的产品，也会和我们共同讨论商业上的一些问题，这就是开源的价值。而最近IBM收购红帽，微软收购GitHub，也都是因为看到了开源的价值，而且开源也确实具有很高的商业价值，才有了这一系列的收购。总之，在硅谷，开源，特别是在To B领域的开源正进行的如火如荼，在国内也有一个非常好的增长趋势。所以，开源无论从技术还是商业上，都对基础软件的发展非常有利。

CSDN：分布式关系型数据库在哪些方面还存在不足？改进的方向在哪里？

申砾：作为一个分布式数据库来说，对于未知应用场景的处理应该说是目前最大的挑战，我们需要去认真思考如何去优化我们的产品，从而在未知场景下，使其依然能够很好的工作。在技术方面，就像阿里巴巴的李飞飞教授所说的那样，分布式关系型数据库或者说分布式数据库是一个远没有解决的问题，各数据库厂商虽然都有自己的方案、架构，但每个方案都有自己的优点和缺点。因此在技术演进路线上还有很多技术问题需要解决，比如说刚才提到的行列缓存怎么去做、冷热数据怎么去分离，包括怎么去利用现有最新的硬件，包括NVM、3D XPoint、FPGA等这样一些先进的硬件技术去加速数据库，跟上硬件的技术潮流，不断改进产品的架构，从而适应技术的演进和业务发展的趋势，是一个非常值得思考的问题。

CSDN：请您展望一下数据库发展的未来？

申砾：数据库现在的趋势是，云厂商做数据库，数据库厂商做云。云厂商做数据库，是因为数据库是非常核心，非常关键的组件，是具有很高商业价值的产品，他们希望能够将之掌握在自己手里。而数据库厂商看到，云是未来的趋势，因此，一定要做云。把数据库放在云端，不管是商业模式也好，运维的简便性也好，扩展方式也好，都是非常便利的。因此，无论对于服务提供商，还是开发者，云都是非常友好的，所以它一定是未来的趋势。对我们来说，我们是独立的第三方，没有云，但很欢迎把我们的数据库部署在各种云上面。另外，在云之外还有很多中小公司，他们可能有自己的机房，想独立部署，此外，还有混合云的方案，因此，我们一方面是希望产品尽可能通用，不需要特殊的硬件、特殊的机房带宽，就能够部署在各种场景之下，让用户能够更简单的使用。另一方面，用户也不用担心厂商的锁定，既可以在此云上部署，也可以在彼云上部署，甚至还可以轻松的从一个云迁到另一个云上。而且我们坚持走开源路线，深度的与用户做沟通交流，让用户知道，我们将尽可能的满足他们的需求，为他们修改、优化需要的各种功能。这样我们就能够在云和数据库厂商之间找到较好的平衡，让我们的数据库产品能够更广泛的传播，做一个真正通用的数据库。当然，我们也不排除在一些云上自己提供数据库服务，就像MongoDB Atlas做的那样。目前，我们在GCP上已经提供了这样的服务，而我们的最终目标，就是要做一个真正通用的数据库产品。

1.微信群：

添加小编微信：color_ld，备注“进群+姓名+公司职位”即可，加入【云计算学习交流群】，和志同道合的朋友们共同打卡学习！

2.征稿：

投稿邮箱：liudan@csdn.net；微信号：color_ld。请备注投稿+姓名+公司职位。

推荐阅读

• 程序员加班很严重吗？看看国外程序员怎么怼老板！
  

• 我地铁都在努力改 Bug，为什么还要裁掉我？
  

• 苹果高通“情变”祸及所有中国 iPhone 用户！
  

• 讲述：一个月薪12000的北京程序员的真实生活
  

• “男医生，女护士？”消除偏见，Google有大招
  

• 数读|DApp现状揭底: 80%活不过一周; 大量游戏营收不到0.5 ETH; EOS已成\"博彩链\"
  

• AWS 吹走了私有云天空中最后一片乌云

• 中国云计算的十年江湖

↓点击“阅读原文”，打开APP 阅读更顺畅