选型宝访谈 | 当业务炸裂式增长，如何让关系型数据库平滑扩展

2019-07-29 本文已影响0人 f81f49b26d88

直播简介

当业务炸裂式增长，如何让关系型数据库平滑扩展？

爱奇艺、饿了么、摩拜单车.....这些国民级应用的疯狂增长背后，是怎样一款国产的分布式NewSQL数据库，在做平滑支撑？

这就是TiDB——一款由中国人自己打造的、新一代分布式关系型NewSQL数据库，而TiDB缔造者，是由一群中国极客创立的开源数据库公司——PingCAP。

PingCAP 的创始团队最早在京东、豌豆荚等大型互联网公司，负责系统架构。当业务炸裂增长时，关系型数据库难以水平扩展，改代码、拆库、拆表、......这些“惨痛经历”成为PingCAP团队创业的动力。用开源的方式，解决“关系型数据水平扩展“的世界级难题，成为PingCAP的创业初心。

伴随着抖音、今日头条、饿了么、摩拜单车这些头部互联网公司的成长，TiDB在开源世界的影响力快速提升。目前TiDB的两个子项目 (TiDB + TiKV) 在 GitHub 社区上已经总共收获超过 19000+ 个Stars。2018年8月28日，TiKV被CNCF接纳为托管项目，这是CNCF基金会全球范围内接纳的第一个 KV Database 项目。

得益于开源的策略，TiDB 加速成熟，除了应用在头部的互联网公司，今天，TiDB也被应用在对产品健壮性、成熟度要求更高的金融行业，最典型的客户是某头部商业银行。

其将 TiDB 作为在线支付业务的核心数据库，经过接近一年的生产考验，其核心支付业务及配套的其它几套关键业务实现了安全高效运行，并在百万级的核心日交易量，稳步增长，顺利度过了诸如“6.18”和“双十一”等关键交易高峰时期。这被 PingCAP 联合创始人、CTO 黄东旭称之为“一个里程碑”，意味TiDB在可靠性、健壮性上，得到了银行级客户的认可。

近日，选型宝邀请到TiDB背后的缔造者之一 ——PingCAP 联合创始人、CTO 黄东旭坐客选型直播

关于这群中国极客如何用开源的理念，立志打造世界级数据库软件的创业历程，关于TiDB的理念、应用场景、案例，一并整理在这篇访谈实录，分享给大家。

对话内容

选型宝：请您简单介绍一下PingCAP团队的背景和创业历程？

黄东旭：好的，从我本人开始说起，其实我上一家公司是在豌豆荚。是个典型的互联网公司，大家知道做安卓应用分发的一个当时很火的公司，再之前其实是在网易有道。都是互联网公司，我在豌豆荚的期间，主要从事他们内部存储系统的运维、管理和分布式存储系统的研发工作，当时这个团队主要去做一些基础的数据库、分布式缓存这样的服务，去支撑互联网公司的快速增长的存储需求。

我们在做TiDB之前，其实做了另外一个开源项目叫Codis，这个缓存项目其实也在很多中国大型的互联网公司用着，因为也是开源的。但是当时，在底层关系型数据库扩展问题上还没有什么优雅的解决方案，特别是我们公司还没有招聘到DBA之前，这些数据库的运维动作都是我这边在做。

当需要扩展数据库的时候，你就半夜不能睡觉，为上线做分库分表，要去手动把数据分片、重新调整，各种各样的非常麻烦的手动操作，会觉得非常原始；而在业务层不能去做这种透明的分布式事务，也不能去做透明的一些复杂查询，业务层也会骂你，为什么你要限制我做这，限制我做那？

所以，自己做了很多工作，但业务层也不爽，后来想有没有办法做一个新的数据库，从根本上去解决在海量数据高并发，同时又能保持着传统的像MySQL这样的透明使用的良好的体验？我当时觉得这是一个行业的普遍痛点，其实包括一些很大的互联网公司也没有一个好的解决方案。

正好，当时也看到了谷歌的几篇论文，他描述了谷歌内部解决这个问题的Spanner、F1这两个系统，我们就想，社区里边正好又没有，那我们就去做第一个，所以就出来成立了这家公司，专门去做这样一个数据库，去解决这样的一个行业通用的痛点问题。

选型宝：您怎么理解数据库技术的发展历程，分几个阶段？

黄东旭：其实整个大的背景大概是这样，上世纪六七十年代就有关系数据库概念了，一直发展到90年代，基本都是以IBM DB2、 Oracle，微软的SQL Server等单机关系型数据库为主的行业现状。

但是在2000年以后，随着互联网行业数据量爆发性的增长，同时最近这5-10年移动互联网的兴起，使得数据量在传统互联网之上又大了一个数量级。我觉得未来在5G包括IOT的时代，可能又会比现在的移动互联网又大一个数量级。所以在互联网蓬勃爆发的阶段，这些互联网公司第一次遇到了大数据的问题。

但是传统的关系型数据库都是一个单机的架构，无论怎么搞，它的弹性伸缩能力其实都是没有的，在这个背景下，在互联网行业里面诞生了NoSQL数据库，就是放弃掉SQL的模型，放弃掉一致性的事务，去换取弹性，通过简单的增加机器，就可以承载互联网的业务。比如说像Twitter、微博，它放弃掉了一致性，对于用户来说，我的业务很简单，就算少看一条微博，丢了，也无所谓，因为不是交易数据。

但是，今天很多业务不仅仅是微博这种形式，那可能也有交易，比如有一些像饿了么订单那样，订单，就不允许发生任何的丢失。谷歌第一个遇到了这样的问题，他们觉得NoSQL没有办法满足广告系统，钱包，这些跟钱有关的业务，数据不能出错，所以他们尝试有没有办法把传统SQL一些好的东西留下来,兼具 NoSQL 扩展性，又不丧失传统关系型数据库 ACID 特性。

另外，有一些分析的场景，比如说我们做了一个活动，想去了解一下活动的效果什么的。如果你在NoSQL上其实很难做这种复杂的分析。比如说对于数据分析师来说，我写几行SQL代码可以做复杂分析，但是如果你是在一个NoSQL系统上，其实你很难做这个事情。

所以现在大家渐渐的发现：我的业务用SQL写还是更方便一点，但是我的扩展性如果是用传统的单机数据库又没法满足需求，所以我们现在在尝试去做的一个事情就是把这两者的好处结合起来，做一个新形态的一种关系型数据库来去服务用户的需求。

我们为什么要从零开始，去完整实现一个NewSQL？因为是这样的，我个人觉得过去这种传统的单机数据库，你也想把它发展成一个通用的分布式数据库，其实这条路是很难走的通的。因为你无论怎么做，你的根基还是一个单机数据库，你无非就是在上面去做一些数据路由层或者说数据分片，仍然还是一个没有去触及本质的修改。

但在TiDB这边，我们其实就放弃了这条路，是从最底层开始去自己构建一套完全面向未来的一个架构，面向未来的这种分布式环境新的一个数据库。所以，你可以认为 TiDB 是从最底层开始，面向分布式场景去做的一个东西。

选型宝：TiDB的整体架构是怎样的？

黄东旭：这里有一张TiDB的整体的架构图，因为本质上来说TiDB自己就是这种集群的形式，也就是说这个系统里面没有任何一个单点，它是可以完全做水平扩展。我简单展开一下，TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server。此外，还有用于解决用户复杂 OLAP 需求的 TiSpark 组件，本身它自己也是微服务的一个思想的实现。

PD Server

红色这个部分就是叫PD的一个小的Cluster ，叫Placement Driver 是存储整个系统原信息的一个模块，你可以认为有点像Hadoop里面的Zookeeper，或者说有点像etcd这样的原信息管理服务。

TiDB Server

绿色这部分是狭义上的TiDB Server，它其实是一层无状态的一个SQL解析层，其本身并不存储数据，只负责计算。你的业务层MySQL的客户端可以连接到任何一个TiKV Server 的实例上，都是一模一样的。所以当你在有海量并发过来的时候，你其实可以连接到任何一个TiKV Server的时候去承载。

TiKV Server

实际上数据的存储是会存储在中间这部分蓝色的叫TiKV的一个组件上。TiKV顾名思义KV，其实它内部本质上是一个Key-Value形式组织的一个分布式数据库，所以TiDB Server这边在做的事情，就是把用户的一个SQL的请求跟表结构这些信息，转换成在TiKV这种分布式的Key-Value的存储，然后把它这个存储下来。这一部分是真正数据存储的位置，同时它是可以做弹性的伸缩、水平扩展，然后分布式事物都是在这一层的这个基础上去实现的。

TiSpark

大家可能会好奇，另外这一块黄色部分是什么部分？

其实最早期在TiDB去设计的时候，只有上述三个大的模块。就是说用户把这三个模块组合在一起，当做一个大型的一个MySQL去用着。但后来有很多用户发现我的数据量在TiDB里面存储的越来越大，几十台甚至上百台机器在去存储数据。

用户就想要在上面去做一些数据分析，在过去传统的方案上，你必须得把数据库里的数据给搬到Hadoop，或者说放到一个离线的数据仓库里才能做分析。但现在用户就在想，TiDB本身不就已经是一个分布式的存储了吗？那我能不能直接拿spark在我这个东西上面去做分析呢？

这块黄色的部分就是我们有一个叫TiSpark的项目，它是spark的一个插件。它把TiDB的一些表结构信息、把一些数据的分布信息，包括我们那些索引信息暴露给spark的执行引擎，能够让spark直接把计算逻辑下推到存储节点上去，做高效的聚合和复杂的分析型的计算。

甚至有些用户是这么用的：这一边用着MySQL去实时的写入，然后马上在这边就用的Spark SQL在同一份数据上去做实时的分析，其实这是一个HTAP的概念。

大体的架构大概是这样。每一个具体的模块里边也都是没有单点的这样一个设计，所以一是它能够很好的去支撑扩容，简单添加TiKV的物理节点就增加了。

如果你的网络流量或者计算能力不够，那你直接添加绿色的部分。你的DBA也不用去重新调整分片，也不需要去重新设计你的路由规则。加一台机器，晚上要回家睡觉了，第二天这个系统自动的就扩容扩好了。

选型宝：能不能给我们分享几个生产环境的案例，讲讲他们是怎么用的，用在什么场景下？

黄东旭：

类型1：OLTP型的应用 ( 支撑了微信12宫格里80%的应用）

其实我想分享几个比较大规模，或者说我们这边觉得比较代表性的几个用户。第一类应用，你可以认为是纯OLTP型的应用，我可以举几个例子，一个是大家知道现在有一个很火的电商公司叫转转，它有点像闲鱼，是58下面的一个二手交易，它入驻的微信的十二宫格。

它其实内部是 ALL IN TiDB的状态，它过去老的方案是各个业务线，各自的一个个MySQL，很传统的一个方案，同时还有一部分MongoDB。但是后来发现,随着入驻微信的十二宫格,业务量的暴涨，他们发现MySQL在不管是高并发压力下延迟的抖动，还有扩展性，其实都没有办法很好地满足它的业务快速增长的要求。

在这种背景下，他们采用了ALL IN TiDB的策略，目前他们内部已经上线了十几套OLTP型的TiDB，包括他们的订单系统，电商商品介绍等这样的系统，还有他们最核心的IM系统，就是聊天系统。因为二手交易的一个特点是，买家在下单之前一定要跟卖家聊天的。所以如果聊天系统出现问题，那这个直接会影响到订单量。聊天的IM表上，他们的设计规模是单表是上千亿条级别。

除了性能和扩展性，TiDB内置的这种两地三中心加上高可用的特性在里面，比如说任何一台物理机宕机了，对整个业务层其实没有任何影响的。

相比于NoSQL 数据库，TiDB的另外一个优势是，它可以让我们不改变平时用 MySQL 的操作习惯，这也是非常吸引转转的地方。

除了转转，我们统计了一下，在微信十二宫格里面80%的应用，也就是基本上有七八个格子里边的应用，背后其实都是由TiDB在执行。

类型2：搭建大中台

另外一个比较有意思的场景是大中台型的业务，过去电商公司，或者说一些大的互联网公司都会特别头疼的一个问题，就是多条不同的业务线，一个个的垂直去划分，每个业务线自己用自己的数据库。你会发现企业缺少一个实时的大中台，能够把不同的业务之间的数据汇总打通。

其实这是一个很大的问题。比如说公司老板，说我今天就要看某某数据，比如说某一个实时销售数据，或者说我要去跟另外一个表去撞一下，去做出一些个性化的一个报表，这个过程会很麻烦。

如果能有一个中间的数据中台，实时的跟多个数据孤岛之间把数据同步给做起来，你在这一层面上变成特别大的一个关系型数据库的数据池子，你就可以很方便地去做这种跨业务、跨分片的复杂的查询。

TiDB是可以直接作为MySQL的从库，它会伪装成MySQL的一个从库去实时地同步线上MySQL主库的数据，因为TiDB是MySQL的语法层面上都兼容的一个数据库，所以我们同时也能直接去同步它的binlog来把数据打通进来。

过去MySQL DBA经常说的一句话就是一主多从，一主挂多个从，现在在TiDB架构里面正好反过来。多主联到一个从，多主一从，数据自然就汇总了。

刚才说的这个大中台案例是同程旅游，同程旅游其实也是微信十二宫格应用中的一个。

类型3：金融级别多数据中心多活

随着 TiDB 的逐渐成熟，TiDB 也已经开始应用在传统金融行业的核心应用，最典型的就是某商业银行，采用了 TiDB 作为在线支付业务的核心数据库。一是使用 TiDB 实现跨三中心的多中心容灾多活核心数据库集群；二是使用 TiDB 承担包括核心网联支付/银联无卡支付业务，支付对账，核心批量作业等一批核心交易应用。

我觉得这个案例，对我们来说更是一个里程碑的意义，并不是说业务量有多大，说实话可能它也没有今日头条的那个系统这么大。但是它的意义就是说可靠性，基本是得到了银行这种金融行业的认可。

刚才我说了几点，我再稍微总结一下：

第一就是海量数据、高并发+弹性扩展的这种互联网的场景

如果你发现你的MySQL，或者说你在内部业务MySQL开始需要分库分表，同时你的业务和DBA都非常不爽，两边都不爽，想到TiDB。

第二个就是你希望去做一个实时的数据中台

用最低的成本、最小的技术栈，去实现数据中台，可以去选择TiDB。

第三个就是说如果你有一些真正的两地三中心、多数据中心多活的金融级别场景

那你也可以去放心的选型TiDB，因为至少已经有很多之前的这些客户已经在上面积累了足够多的经验。

所以我觉得这几点，是TiDB现在来说比较擅长的，而且因为TiDB是兼容MySQL的，所以易用性来说，就是说如果你的应用已经是基于MySQL开发的，你不需要做很大的改动。

选型宝：你们是从解决关系型数据库扩展的问题切入，当然，您刚才也提到了这样一种架构，为客户带来很多方面的价值，请您总结一下，TiDB分布式的架构，为用户带来的价值，体现在哪些方面？

黄东旭：首先，我觉得扩展性是对于这种新型分布数据库的一个及格线

这是一个基础。现在这个年代你再做一个单机型的数据库，其实没有什么太大意义。