阿里下一代数据库技术：把数据库装入容器不再是神话

转载自：https://mp.weixin.qq.com/s/AIZQ5-F5AngdIESNCXngWw

张瑞，阿里集团数据库技术团队负责人，阿里巴巴研究员，Oracle ACE。双十一数据库技术总负责人，曾两次担任双十一技术保障总负责人。自2005年加入阿里巴巴以来，一直主导整个阿里数据库技术的不断革新。

近日，在京举行的2017中国数据库技术大会上，来自阿里巴巴集团研究员张瑞发表了题为《面向未来的数据库体系架构的思考》的主题演讲。主要介绍了阿里数据库技术团队正在建设阿里下一代数据库技术体系的想法和经验，希望能够把阿里的成果、踩过的坑以及面向未来思考介绍给与会者，为中国数据库技术的发展出一份力。

演讲全文：

我先介绍一下我自己，我2005年加入阿里一直在做数据库方面的工作，今天这个主题是我最近在思考阿里巴巴下一代数据库体系方面的一些想法，在这里分享给大家，希望能够抛砖引玉。大家如果能够在我今天分享后，结合自己面对的实际场景，得到一些体会，有点想法的话，我今天分享的目的就达到了。

今天我会讲以下几方面内容：首先讲一下我们在内核上的一点创新、数据库怎么实现弹性调度、关于智能化的思考、最后是曾经踩过的坑和看到未来的方向。

阿里场景下数据库所面临的问题

首先说一下，阿里巴巴最早一代使用的数据库技术是Oracle，后面大家也知道一件事情就是去IOE，去IOE过程中我们迈向了使用开源数据库的时代，这个时代今天已经过去，这个过程大概持续了五六年，整个阿里巴巴有一个大家都知道的开源MYSQL分支--AliSQL，我们在上面做了大量的改进，所以我这里列了一下在AliSQL上的一些改进，但今天我实际上并不想讲这个，我想讲一下面向未来的下一代数据库技术、数据库架构会往哪个方向走。

我觉得是这样的，因为今天的阿里巴巴毕竟是一个技术的公司，所以很多时候我们会看比如说Google或者是一些互联网的大的公司，他们在技术上创新点来自于哪里？来自于问题。就是说今天在座的各位和我是一样的，你所面对场景下的问题是什么、你看问题深度如何决定了你今天创造的创新有多大。

所以今天我们重新看一下阿里面临的问题是什么，相信在座的各位一定也有这样的想法，阿里所面临的问题不一定是你们的问题，但我想说今天通过阿里面临的问题，以及我们看到这些问题后所做的事情，期待能够给大家带来参考，希望大家也能够看到自己所面临的问题是什么，你将如何思考。

可以看到其实阿里巴巴的应用和Facebook、Google的还是有很大区别的，我们也找他们做了交流，发现跟他们的业务场景真的不一样，首先我们的主要应用是交易型的，这些应用会有些什么要求，你会看到有这些点（见图片），下面主要讲一下我们的思考。

今天数据的高可用和强一致是非常重要的，数据不一致带来的问题是非常非常巨大的，大家也用淘宝，也是阿里巴巴一些服务的用户，数据不一致带来的问题，每一个用户、甚至我的父母都会关注这些事情。

第二，今天存储成本是非常高的，所有的数据中心已经在用SSD，但数据的存储成本依然是一个大型企业面临的一个非常大的问题，这都是实实在在钱的问题。

另外刚才也提到了，数据都是有生命周期的，那么数据尤其是交易数据是有非常明显的冷和热的状态，大家一定很少看自己一年前在淘宝的购买记录，但是当下的购买记录会去看，那系统就需要经常会去读它、更新它。

还有一个特点是今天阿里的业务还是相对简单的，比如我们要在OLTP性能上做到极致性。还有一个阿里巴巴特有的点就是双十一，双十一本质上是什么，本质上就是制造了一个技术上非常大的热点效应。这对我们提出什么样的需求呢？需求就是一个极致弹性的能力，数据库实际上在这个方向是非常欠缺的，数据库怎么样去做到弹性伸缩是非常难的事情。

最后我想说说DBA，今天在座的很多人可能都是DBA，我想说一下阿里在智能化这个方向上得到的思考是什么样的，我们有海量的数据，我们也有很多经验很丰富的DBA，但这些DBA怎么样去完成下一步的转型、怎么样不成为业务的瓶颈？数据库怎么样做到自诊断、自优化。这是我们看到的问题，最后我也会来分享一下我在这方面的思考。

阿里在数据库内核方向上的思考

我先讲一下我们在数据库内核上的思考。首先我很尊敬做国产数据库的厂商，凡是在内核上改进的人都知道，其实每个功能都是要一行行代码写出来都是非常不容易的，我想表达对国产数据库厂商包括这些技术人的尊敬。今天我要讲的内容是我第一次在国内的会议上来讲，首先我会讲一下AliSQL X-Cluster。X-Cluster是在AliSQL上做的一个三节点集群，这是我们在引入了Paxos一致性协议，保证MySQL变成一个集群，并且这个集群具有数据强一致、面向异地部署，且能够容忍网络高延迟等一系列特性。

今天很多数据库都会和Paxos联系在一起，比如大家都知道的Google的Spanser数据库，但是以前大家没有特别想过数据库和Paxos会有什么关系，其实以前确实没有什么关系的，但是今天的数据库在几个地方是需要用到Paxos协议的，第一个我们需要用Paxos来选举，尤其在高可用的场景下需要唯一地选举出一个节点作为主节点，这就需要用到Paxos；第二是用Paxos协议来保证数据库在没有共享存储的前提下数据的强一致，就是数据怎么样在多个节点间保证是强一致，且保证高可用。

所以说现在的数据库架构设计上Paxos的应用非常广泛，今天外面很多展商包括Goolge Spanser也都在用Paxos协议和数据库结合在一起来做。所以AliSQL的三节点集群也是一样，就是利用Paxos协议变成一个数据强一致的集群。下面我大概解释一下Paxos协议在数据库里的作用是什么。

本质上来说Paxos也是现在通用的技术，大家都是搞数据库的，简单来说，Paxos协议用在我们数据库里面，就是一个事务组的提交在一个节点并落地后，必须在多个节点同时落地，也就是说原来写入只需要写入一个节点上，但是现在需要跨网络写到另外一个节点上，这个节点可能是异地的，也可能是全球的另外一个城市，中间需要经过非常漫长的网络时延，这时候需要有一些核心技术。

我们的目标是什么？首先没有办法抗拒物理时延，过去在数据库上的操作只要提交到本地，但现在数据库全球部署、异地部署，甚至跨网络，这个时延特性是没有办法克服的，但是在这种情况下我们能做到什么？在时延增长情况下尽可能保证吞吐不下降，原来做多少QPS、TPS，这一点是可以保证的，只要工程做的好是可以保证的，但是时延一定会提升。

这也是大家经常在Goolgle Spanser论文里看到的“我的时延很高”的描述，在这种时延很高的情况下，怎么样写一个好的应用来保证可用、高吞吐，这是另外一个话题。大家很长一段时间里已经习惯一个概念，那就是数据库一定是时延很低的，时延高就会导致应用出问题，实际上这个问题要花另外一个篇幅去讲，那就是应用程序必须要去适应这种时延高的数据库系统。当然用了Batching和Pipelining技术，本质上是通用的工程优化，让跨网络多复本同步变的高效，但是时延一定会增加。

实际上大家知道数据库要做三副本或者三节点，本质上就是为了实现数据强一致，而且大家都在这个方向上做努力，比如Oracle前一段时间推出的Group replication，也是三节点技术，X-Cluster和它的区别是，我们一开始的目标就是跨城市，最开始设计的时候就认为这个节点一定要跨非常远的距离来部署的，设计之初提出这个目标造成我们设计上、工程实践上、包括最终的性能上有比较大的差异。

这里我们也做了一些X-Cluster和Oracle的Group replication的对比，同城的环境下我们要比他们好一些；在异地场景下这个差异就更大了，因为我们本来设计的时候就是面向异地的场景。可能大家也知道，阿里一直在讲异地多活的概念，就是IDC之间做异地多活怎么样能够做到，所以最开始我们设计的就是面向异地的场景做的。

这是一个典型的X-Cluster在异地多活的场景下怎么做的架构图，这是一个典型的3城市4份数据5份日志架构，如果要简化且考虑数据存储成本的话，实际上可以做到3份数据5份日志，这样的话就可以保证城市级、机房机、包括单机任何的故障都可以避免，并且是零数据丢失的，在今天我们可以这么做，且能保证数据是零丢失、强一致的。在任何一个点上的数据至少会被写到另一个城市的数据中心的数据库里面，这是我们X-Cluster设计之初的目标，这也是一个典型的异地多活的架构。

再讲一个小的，但是非常实用的创新点，可能大家都比较感兴趣，这就是X-KV。这里还要说一下，我们所有的下一代技术组件都是以X开头的。这个X-KV是基于原来MYSQL的Memcached plugin做的改进，做到非常高的性能，大家可能都了解MySQL的Memcached plugin，可以通过Memcached plugin的接口直接访问InnoDB buffer 里的数据，读的性能可以做到非常高，这对于大家来说，或者对于所谓的架构师，或者设计的过程中意义在什么地方呢？

那就是很多场景下不需要缓存了，因为数据库+缓存结构基本上是所有业务通用的场景，但是缓存的问题在于缓存和数据库里的数据永远是不一致的，需要一个同步或者失效机制来做这个事情。使用X-KV后读的问题基本上就能解决掉。这是因为一份数据只要通过这个接口访问就基本上做到和原来访问缓存差不多的能力，或者说在大部分情况下其实就不需要缓存了。

第二是说它降低了应用的响应时间，原来用SQL访问的话响应时间会比较高，我们在这上面做了一些改进，本来Memcached plugin插件有一些支持数据的类型限制，包括对一些索引类型支持不太好，所以我们做了改进，这个大家都可以用的，如果用这个方式的话基本上很多缓存系统是不需要的。

第三个事情我想讲一下怎么样解决冷热数据分离的，我们天然地利用了MySQL的框架，这里就直接拿了MySQL的大图来展示，大家可以看到MySQL本质上来说就是上面有个Client，中间有个Server，底下有个存储层，在存储层里面可以有各种各样的引擎，所以通过不同的引擎可以实现不同的特性。大家今天最常用的就是InnoDB引擎，每个存储引擎的特性本质上是由其结构造成的。比如InnoDB采用B+ Tree的结构，它带来的特性就是相对来说读和写都比较均衡，因为发展了这么多年确实是比较成熟的。

比如我们现在选择RocksDB，这是因为我们和Facebook在RocksDB上有一些合作，就是把它引入到MySQL上面，它本质的结构是LSM Tree，这个结构就带来的好处包括写入比较友好、压缩的特性好等。把它引入进来对我们的改革还不仅仅是引入了一个结构，而是今天我们用这两种引擎解决我们今天数据分离的问题。我们也跟Facebook有过一些交流，RocksDB今天并没有那么稳定、那么好，但是作为InnoDB存储引擎的补充的话，是非常有效的。

尤其在稳定数据库的背景下，用户今天怎么样才能对自己的数据的冷热没有太多的感觉，因为大家可能也知道，你们以前也有一些数据的分离，但是对应用方来说，需要把数据从某个存储倒到某个存储里，然后再删掉；或者动不动DBA去找业务开发方说你的存储空间不够了，占用很多空间，能不能删一些数据或者把这些数据导入到成本更低的存储引擎里。我们经常这么干，这里说的直白一点，我相信大家都这么干过。

但是用这种双引擎结构的话，RocksDB压缩率高的特性，特别是OLTP行存储的场景下，能够给我们带来比较大的收益。所以我们可以把这两个引擎在MySQL特性下面把它结合起来，并且可以利用到比较廉价的架构，尤其是LSM Tree这种架构，他对廉价的存储介质是比较友好的，因为他的写都是顺序写的。这就是我们今天在数据库内核上面的一些思考。

数据库为什么要实现弹性调度

第二部分，我想说一下数据库弹性调度这个事，大家都知道阿里双十一，双十一对我们来说最大的挑战就是应用程序可能已经很容易去做弹性调度，包括上云、弹性扩容和缩容，但是数据库确实比较难，我们也在这上面也探索了一段时间，今天会把我们的思考分享给大家。

我之前听好多人说数据库容器化是个伪命题，为什么要做容器化，为什么要把数据库放到容器里呢？第二也有一些新技术，比如刚才的分享嘉宾也提到的，把存储放在远端通过网络访问是可能的。但是我们从正向来思考，先别想数据库弹性调度可能不可能，数据库如果要实现弹性调度，它的前提是什么？

我们先去想数据库要像应用一样非常简单的弹性调度，那么数据库要做到什么？我觉得有两大前提是必须要做的：1、它必须要放到一个容器里；2、计算和存储必须分离。因为如果计算和存储本质上不分离的话，数据库基本上没有办法弹性调度。大家知道计算资源是很容易被移动的，但是存储资源基本上很难在短时间内移动它，所以做弹性是非常非常困难的。所以这是两大基础条件。

在我们的场景下如果你也碰到这种问题的话，那就不是伪命题，我觉得这个东西合不合理，更多时候不是技术有没有正确性，而是在你的场景下是否需要它，所以今天我们就做了两件事情，第一是把它放到容器里面，我们目前物理机，VM和Docker都在支持，有一层会把容器的复杂性屏蔽掉，数据库一定要放到容器里。应用程序放到容器里很多时候是为了部署，但是我们把数据库放容器里就是为了做调度，因为数据库本身没有特别多的发布，不需要像应用一样做频繁发布。做了容器化之后，数据库在一个物理机上可以和其他的容器做混部。

我们做DBA的都有一些传统的观点，比如数据库服务器上肯定不能跑应用，数据库肯定是不能用容器的。不知道在座的各位，每当有人或者你的老板问你这个问题的时候，你是不是从来都是马上回绝他说“数据库肯定不能这么做”，但是今天你也许可以告诉你的老板可以试一试。

存储计算分离，最早做数据库的时候，存储和计算其实就是分离的，用一个Oracle的数据库，用一个SAN网络，底下接一个存储，存储和计算本身就是分离的，中间用SAN网络连起来。然后演进到用Local的盘，用SSD盘，用PC做服务器。，那未来重新要回到存储和计算分离的结构下，今天的网络技术的发展，不说专有网络，就说通用的25G网络，还有RDMA和SPDK等新技术的使用，让我们具备了存储计算分离的能力，让数据库存储计算分离的条件已经具备。

今天在数据库上已经看到大量优化的特性可以减少IO，可以把离散的IO变成顺序的IO，可以对下层的存储做的很友好。从存储成本上来说，共享存储会极大的降低成本，是因为存储碎片会被极大地压缩，因为原来每个机器上都空闲30%、50%的空间，其他的机器是很难利用到的，当你今天把这些碎片变成一个Pool的时候是有很大收益的。

还有数据库未来如果采用存储和计算分离的话，就会打破目前主流的数据库一主一备的架构，这个架构至少有一半的计算资源是被完全浪费的，不管你的备库是否用来做报表或者其他的应用，但是基本是浪费的。如果可以做到共享存储，那这将是一个巨大的收益。这是我们在调度上的思考，明天分会场上也会有一个阿里同学就这个主题给大家做容器和存储资源上的细节介绍，我今天只讲了一个大概。

DBA未来的工作内容是什么？

最后讲一下DBA的事情，刚才也在说，我这里说从自动化走向智能化，我们内部讲从自助化走向智能化，不知道大家是不是受到一个困扰，业务发展的速度远远大于DBA人数的增长，如果你没有后面的这些我可以不讲了，但是如果你有，你可以听一下我们在这方面的思考，我们也碰到同样的问题，DBA要怎么样的发展，自动化的下一步应该做什么，很多人说DBA是不是会被淘汰掉，至少我们想清楚了这些问题之后，阿里的DBA不纠结这个事情，所以我今天跟大家分享一下这个思考。

首先我们今天做了一个事情，我们放弃了原来的思路，原来的思路是什么呢？最早的时候我们每个上线的SQL都需要DBA看一下；第二个阶段，我们做了一个系统，在每个SQL上线之前系统都要预估一下它的性能好不好，如果好才上线。所有我们今天觉得最大的变化和思考是什么？所有基于单条语句的优化都是没有特别多意义的，因为只有基于大的数据和计算，才有可能变成一个智能化的东西，否则都是基于规则的。

基于规则的系统是很难有特别长久的生命力，因为有永远写不完的规则。我们也曾经做过这样的尝试，一些SQL进来的时候，系统要对它进行一些判断，最后发现永远写不完的规则。所以后来我们就找到了另外一个方向，我相信今天在座的所有人，你所在的公司不论大小都都有一个监控系统，我们就从这个监控系统出发，怎么样把一个监控系统变成一个智能的优化引擎，我们在这里也不说是大脑，就说是引擎好了。这个引擎会做什么？

首先来说，我们已经放弃掉基于单条SQL的优化，因为没有意义，DBA也没有审阅单条SQL，系统去看单条SQL的意义也不大。今天我们的第一个场景是说大量的数据，大量的数据是什么？我们就从我们的监控系统出发，提出了第一个目标，把每一条运行的SQL采集下来，不是采样，是每一条。在规模比较大的系统来说对存储来说是个巨大的压力，因为这样会产生大量的副产品。

就像Facebook在做监控产品时产生的时序数据库一样，今天我们产生的副产品也是在时序数据库方面带来压力，这个具体的我今天先不展开。我们采集每一条SQL的运行情况，因为我们在内核里做了改进，可以把每条SQL的来源、路径、以及它在数据库里所有的信息全部采集下来。把监控指标压到秒级，所有监控项的指标必须最小达到秒级，这是我们现有的技术能够做到的。

另外，我们把应用端日志和数据库结合在一起。原来做数据库的时候，应用方吼一嗓子说“数据库有没有问题啊”DBA说没有问题。但是从应用那端看，其实看到数据库有很多问题，包括应用报错，包括响应时间，把应用端报错也要和数据库结合在一起，尤其是应用里面报数据库的错误，以及这一整条链路。

响应时间，只有应用端的响应时间才是真正意义上可以衡量一个数据库是不是好的指标，而不是数据库本身怎么样，什么Load低啊，CPU利用率多少。当把这些数据全部采集下来之后，这些大量的时序数据我们叫做副产品，这对我们整个链路产生了一个巨大的压力。我们做整个监控系统平台的同学觉得日子要活不下去了，因为原来的存储系统支撑不了、分析系统支撑不了、原来的平台计算不出来。所以先从这个目标考虑，基于链路做了巨大的改进，包括怎么样实现廉价存储、怎么样实时分析，这是存储和计算的要求。

我们今天这个目标是在阿里内部明确提的，我们希望两到三年内希望大部分把DBA的工作替换掉，我不知道两到三年能不能做到，我希望能做到。其实今天DBA是这样的，DBA的工作本质上分为两类，第一类就是运维，但运维本质上来说是比较好解决的，不管是用云，小公司用云全搞定，大公司基本上都有一些自动化运维的系统。

但是最难解决的就是刚才我说的诊断和优化。我也了解过很多公司，比如说Google、facebook，我说你们为什么没有DBA呢？他们说我们没有DBA，没有像国内这种特别传统的针对诊断和性能优化的DBA，这种职责很少。所以这个东西希望能够做到。

最后我们有了数据、有了计算，我们觉得未来的方向可能就是现在比较火的机器学习，这个主题明天也有一个阿里同学会来分享，机器学习这里我就不多讲了，因为我觉得我们也在入门，所以没有什么值得讲的，但是我们觉得这个设计挺有戏的，你只要积累足够的数据和计算的话这个事情还是挺有戏的。

我们对数据库未来的其他思考

最后一页PPT我用大白话讲一下我对整个数据库体系的一些理解。

今天在一个公司里边没有一个存储或者是数据库可以解决所有问题，今天越来越多的趋势看到，数据存储的多样性是必然会存在的，因为行存有行存的优势、列存有列存的优势、做计算有计算的优势、做分析有做分析的优势、做OLTP有OLTP的优势，不要指望，或者很难指望一个系统干所有的事情很，这个话我说了可能不太好，但是确实比较难，但是我们看到的一点是什么？就是每个技术或产品在生产中干一件事情可以干到最好，你就用它做的最好的那件事解你的问题就好了。

这就回到之前的问题，我们也走过一些弯路，数据存储类型越来越多，今天用这个明天用那个，怎么办？我们的运维没法搞定，这个支持很痛苦。

所以今天我们建议建立两个平台：1、建立一个支撑的平台，这个支撑的平台尽可能把下层存储的复杂性屏蔽掉，对上层提供统一的接口和服务；2、建立一个服务的平台，明确面向研发的平台，研发人员可以直接通过这个平台来用数据库的服务。我看到很多公司把运维平台和DBA开发的平台混在一起，但阿里的思路是，支撑平台和服务平台是两个分层的平台，支撑平台在下面，上层服务平台为所有的开发人员服务，开发人员上了这个平台就能看到我用了什么数据库，性能怎么样，在上面可以做什么事情，这样就可以大量节省DBA的人力。

我们内部有句开玩笑的话叫“不节省人力的平台、不节省成本的技术都是耍流氓”，这句话怎么讲？就是说我们的自动化系统，尤其是大公司越建越多，最后的结果就是人没有能力了，我不知道大家有没有这个问题，这就是我最后讲的一点，自动化系统的悖论。每个公司每个人今天你们在做自动化系统的过程中有没有发生一件事情？反正在阿里是发生了，就是人的能力弱化了。

这个自动化系统的悖论是我们无意中看到的，在讲飞机的自动驾驶的时候，因为自动驾驶做的足够好，当出现紧急问题的时候，飞机驾驶员反而没有足够的能力去处理紧急的情况，这就是自动化系统的悖论。

可以对比看一下，我们今天做了很多自动化系统，结果人只会点系统，系统一卡壳就完蛋，很多次生故障都是出现在系统卡壳，卡壳人搞不定，怎么办？这是今天要去想的问题，在这个过程中今天所有带团队的或者今天在这个体系的人都要思考的问题，我们也在直面这个问题，让人的能力和系统的能力能够结合在一起，这是另外一个话题，我今天不能给出答案，但是要特别重视这些问题。

不要相信那些已经过期的神话，数据库存储和计算是可以分离的，数据库也是可以放在容器里的，但你真的要去看一下，原来那些神话或者是那个背后它的问题到底是什么，其实现在可能都已经有解法了，所以在座的各位，当你的老板、CTO或者什么人来问你“能不能做到这样？”我希望你能告诉他“我能！”

我们内部有一句话原来我们的DBA哪里看过一篇文章，说DBA的概念是什么？我印象特别深，有一个开发的同学在底下的回复是说“DBA就是一群永远在说不的人”就是不能这样不能那样，我们今天我觉得未来我们变成一群永远可以说“yes”，说“可以”的人，谢谢！