《面向未来的数据库体系架构思考--把数据库装入容器》由会员分享，可在线阅读，更多相关《面向未来的数据库体系架构思考--把数据库装入容器（16页珍藏版）》请在金锄头文库上搜索。
1、面向未来的数据库体系架构思考-把数据库装入容器介绍了阿里数据库技术团队正在建设阿里下一代数据库技术体系的想法和经验在京举行的2021中国数据库技术大会上，来自阿里巴巴集团研究员张瑞发表了题为?面向未来的数据库体系架构的思考?的主题演讲，主要介绍了阿里数据库技术团队正在建设阿里下一代数据库技术体系的想法和经验，希望能够把阿里的成果、踩过的坑以及面向未来思考介绍给与会者，为中国数据库技术的开展出一份力。如下：我先介绍一下我自己，我2005年参加阿里一直在做数据库方面的工作，今天这个主题是我最近在思考阿里巴巴下一代数据库体系方面的一些想法，在这里分享给大家，希望能够抛砖引玉。大家如果能够在我今天分享
2、后，结合自己面对的实际场景，得到一些体会，有点想法的话，我今天分享的目的就到达了。今天我会讲以下几方面内容：首先讲一下我们在内核上的一点创新、数据库怎么实现弹性调度、关于智能化的思考、最后是曾经踩过的坑和看到未来的方向。阿里场景下数据库所面临的问题首先说一下，阿里巴巴最早一代使用的数据库技术是Oracle，后面大家也知道一件事情就是去IOE，去IOE过程中我们迈向了使用开源数据库的时代，这个时代今天已经过去，这个过程大概持续了五六年，整个阿里巴巴有一个大家都知道的开源MYSQL分支-AliSQL，我们在上面做了大量的改良，所以我这里列了一下在AliSQL上的一些改良，但今天我实际上并不想讲这个
3、，我想讲一下面向未来的下一代数据库技术、数据库架构会往哪个方向走。我觉得是这样的，因为今天的阿里巴巴毕竟是一个技术的公司，所以很多时候我们会看比方说Google或者是一些互联网的大的公司，他们在技术上创新点来自于哪里？来自于问题。就是说今天在座的各位和我是一样的，你所面对场景下的问题是什么、你看问题深度如何决定了你今天创造的创新有多大。所以今天我们重新看一下阿里面临的问题是什么，相信在座的各位一定也有这样的想法，阿里所面临的问题不一定是你们的问题，但我想说今天通过阿里面临的问题，以及我们看到这些问题后所做的事情，期待能够给大家带来参考，希望大家也能够看到自己所面临的问题是什么，你将如何思考。可
4、以看到其实阿里巴巴的应用和Facebook、Google的还是有很大区别的，我们也找他们做了交流，发现跟他们的业务场景真的不一样，首先我们的主要应用是交易型的，这些应用会有些什么要求，你会看到有这些点见图片，下面主要讲一下我们的思考。今天数据的高可用和强一致是非常重要的，数据不一致带来的问题是非常非常巨大的，大家也用淘宝，也是阿里巴巴一些效劳的用户，数据不一致带来的问题，每一个用户、甚至我的父母都会关注这些事情。第二，今天存储本钱是非常高的，所有的数据中心已经在用SSD，但数据的存储本钱依然是一个大型企业面临的一个非常大的问题，这都是实实在在钱的问题。另外刚刚也提到了，数据都是有生命周期的，那
5、么数据尤其是交易数据是有非常明显的冷和热的状态，大家一定很少看自己一年前在淘宝的购置记录，但是当下的购置记录会去看，那系统就需要经常会去读它、更新它。还有一个特点是今天阿里的业务还是相对简单的，比方我们要在OLTP性能上做到极致性。还有一个阿里巴巴特有的点就是双十一，双十一本质上是什么，本质上就是制造了一个技术上非常大的热点效应。这对我们提出什么样的需求呢？需求就是一个极致弹性的能力，数据库实际上在这个方向是非常欠缺的，数据库怎么样去做到弹性伸缩是非常难的事情。最后我想说说DBA，今天在座的很多人可能都是DBA，我想说一下阿里在智能化这个方向上得到的思考是什么样的，我们有海量的数据，我们也有很
6、多经验很丰富的DBA，但这些DBA怎么样去完成下一步的转型、怎么样不成为业务的瓶颈？数据库怎么样做到自诊断、自优化。这是我们看到的问题，最后我也会来分享一下我在这方面的思考。阿里在数据库内核方向上的思考我先讲一下我们在数据库内核上的思考。首先我很尊敬做国产数据库的厂商，但凡在内核上改良的人都知道，其实每个功能都是要一行行代码写出来都是非常不容易的，我想表达对国产数据库厂商包括这些技术人的尊敬。今天我要讲的内容是我第一次在国内的会议上来讲，首先我会讲一下AliSQL X-Cluster。X-Cluster是在AliSQL上做的一个三节点集群，这是我们在引入了Paxos一致性协议，保证MySQL变
7、成一个集群，并且这个集群具有数据强一致、面向异地部署，且能够容忍网络高延迟等一系列特性。今天很多数据库都会和Paxos联系在一起，比方大家都知道的Google的Spanser数据库，但是以前大家没有特别想过数据库和Paxos会有什么关系，其实以前确实没有什么关系的，但是今天的数据库在几个地方是需要用到Paxos协议的，第一个我们需要用Paxos来选举，尤其在高可用的场景下需要唯一地选举出一个节点作为主节点，这就需要用到Paxos；第二是用Paxos协议来保证数据库在没有共享存储的前提下数据的强一致，就是数据怎么样在多个节点间保证是强一致，且保证高可用。所以说现在的数据库架构设计上Paxos的应
8、用非常广泛，今天外面很多展商包括Goolge Spanser也都在用Paxos协议和数据库结合在一起来做。所以AliSQL的三节点集群也是一样，就是利用Paxos协议变成一个数据强一致的集群。下面我大概解释一下Paxos协议在数据库里的作用是什么。本质上来说Paxos也是现在通用的技术，大家都是搞数据库的，简单来说，Paxos协议用在我们数据库里面，就是一个事务组的提交在一个节点并落地后，必须在多个节点同时落地，也就是说原来写入只需要写入一个节点上，但是现在需要跨网络写到另外一个节点上，这个节点可能是异地的，也可能是全球的另外一个城市，中间需要经过非常漫长的网络时延，这时候需要有一些核心技术。
9、我们的目标是什么？首先没有方法抗拒物理时延，过去在数据库上的操作只要提交到本地，但现在数据库全球部署、异地部署，甚至跨网络，这个时延特性是没有方法克服的，但是在这种情况下我们能做到什么？在时延增长情况下尽可能保证吞吐不下降，原来做多少QPS、TPS，这一点是可以保证的，只要工程做的好是可以保证的，但是时延一定会提升。这也是大家经常在Goolgle Spanser论文里看到的“我的时延很高的描述，在这种时延很高的情况下，怎么样写一个好的应用来保证可用、高吞吐，这是另外一个话题。大家很长一段时间里已经习惯一个概念，那就是数据库一定是时延很低的，时延高就会导致应用出问题，实际上这个问题要花另外一个篇
10、幅去讲，那就是应用程序必须要去适应这种时延高的数据库系统。当然用了Batching和Pipelining技术，本质上是通用的工程优化，让跨网络多复本同步变的高效，但是时延一定会增加。实际上大家知道数据库要做三副本或者三节点，本质上就是为了实现数据强一致，而且大家都在这个方向上做努力，比方Oracle前一段时间推出的Group replication，也是三节点技术，X-Cluster和它的区别是，我们一开始的目标就是跨城市，最开始设计的时候就认为这个节点一定要跨非常远的距离来部署的，设计之初提出这个目标造成我们设计上、工程实践上、包括最终的性能上有比拟大的差异。这里我们也做了一些X-Clust
11、er和Oracle的Group replication的比照，同城的环境下我们要比他们好一些；在异地场景下这个差异就更大了，因为我们本来设计的时候就是面向异地的场景。可能大家也知道，阿里一直在讲异地多活的概念，就是IDC之间做异地多活怎么样能够做到，所以最开始我们设计的就是面向异地的场景做的。这是一个典型的X-Cluster在异地多活的场景下怎么做的架构图，这是一个典型的3城市4份数据5份日志架构，如果要简化且考虑数据存储本钱的话，实际上可以做到3份数据5份日志，这样的话就可以保证城市级、机房机、包括单机任何的故障都可以防止，并且是零数据丧失的，在今天我们可以这么做，且能保证数据是零丧失、强一
12、致的。在任何一个点上的数据至少会被写到另一个城市的数据中心的数据库里面，这是我们X-Cluster设计之初的目标，这也是一个典型的异地多活的架构。再讲一个小的，但是非常实用的创新点，可能大家都比拟感兴趣，这就是X-KV。这里还要说一下，我们所有的下一代技术组件都是以X开头的。这个X-KV是基于原来MYSQL的Memcached plugin做的改良，做到非常高的性能，大家可能都了解MySQL的Memcached plugin，可以通过Memcached plugin的接口直接访问InnoDB buffer 里的数据，读的性能可以做到非常高，这对于大家来说，或者对于所谓的架构师，或者设计的过程中
13、意义在什么地方呢？那就是很多场景下不需要缓存了，因为数据库+缓存结构根本上是所有业务通用的场景，但是缓存的问题在于缓存和数据库里的数据永远是不一致的，需要一个同步或者失效机制来做这个事情。使用X-KV后读的问题根本上就能解决掉。这是因为一份数据只要通过这个接口访问就根本上做到和原来访问缓存差不多的能力，或者说在大局部情况下其实就不需要缓存了。第二是说它降低了应用的响应时间，原来用SQL访问的话响应时间会比拟高，我们在这上面做了一些改良，本来Memcached plugin插件有一些支持数据的类型限制，包括对一些索引类型支持不太好，所以我们做了改良，这个大家都可以用的，如果用这个方式的话根本上很
14、多缓存系统是不需要的。第三个事情我想讲一下怎么样解决冷热数据别离的，我们天然地利用了MySQL的框架，这里就直接拿了MySQL的大图来展示，大家可以看到MySQL本质上来说就是上面有个Client，中间有个Server，底下有个存储层，在存储层里面可以有各种各样的引擎，所以通过不同的引擎可以实现不同的特性。大家今天最常用的就是InnoDB引擎，每个存储引擎的特性本质上是由其结构造成的。比方InnoDB采用B+ Tree的结构，它带来的特性就是相对来说读和写都比拟均衡，因为开展了这么多年确实是比拟成熟的。比方我们现在选择RocksDB，这是因为我们和Facebook在RocksDB上有一些合作，
15、就是把它引入到MySQL上面，它本质的结构是LSM Tree，这个结构就带来的好处包括写入比拟友好、压缩的特性好等。把它引入进来对我们的改革还不仅仅是引入了一个结构，而是今天我们用这两种引擎解决我们今天数据别离的问题。我们也跟Facebook有过一些交流，RocksDB今天并没有那么稳定、那么好，但是作为InnoDB存储引擎的补充的话，是非常有效的。尤其在稳定数据库的背景下，用户今天怎么样才能对自己的数据的冷热没有太多的感觉，因为大家可能也知道，你们以前也有一些数据的别离，但是对应用方来说，需要把数据从某个存储倒到某个存储里，然后再删掉；或者动不动DBA去找业务开发方说你的存储空间不够了，占用
16、很多空间，能不能删一些数据或者把这些数据导入到本钱更低的存储引擎里。我们经常这么干，这里说的直白一点，我相信大家都这么干过。但是用这种双引擎结构的话，RocksDB压缩率高的特性，特别是OLTP行存储的场景下，能够给我们带来比拟大的收益。所以我们可以把这两个引擎在MySQL特性下面把它结合起来，并且可以利用到比拟廉价的架构，尤其是LSM Tree这种架构，他对廉价的存储介质是比拟友好的，因为他的写都是顺序写的。这就是我们今天在数据库内核上面的一些思考。数据库为什么要实现弹性调度第二局部，我想说一下数据库弹性调度这个事，大家都知道阿里双十一，双十一对我们来说最大的挑战就是应用程序可能已经很容易去做弹性调度，包括上云、弹性扩容和缩容，但是数据库确实比拟难，我们也在这上面也探索了一段时间，今天会把我们的思考分享给大家。我之前听好多人说数据库容器化是个伪命题，为什么要做容器化，为什么要把数据库放到容器里呢？第二也有
