01

直播简介

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

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

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

02

对话内容

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

黄东旭：其实整个大的背景大概是这样，上世纪六七十年代就有关系数据库概念了，一直发展到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 是从最底层开始，面向分布式场景去做的一个东西。

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

黄东旭：

类型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开发的，你不需要做很大的改动。