前面不久,在京举行的中国数据库技术大会上,来自阿里巴巴集团研究员张瑞发表了题为《面向未来的数据库体系架构的思考》的主题演讲。
主要介绍了阿里数据库技术团队正在建设阿里下一代数据库技术体系的想法和经验,希望能够把阿里的成果、踩过的坑以及面向未来思考介绍给与会者,为中国数据库技术的发展出一份力。
简介:
张瑞,阿里巴巴研究员,阿里集团数据库技术团队负责人,经历阿里数据库技术变革历程,连续六年作为数据库总负责人参与双11备战工作。
演讲大致内容:
我先介绍一下我自己,我2005年加入阿里一直在做数据库方面的工作,今天这个主题是我最近在思考阿里巴巴下一代数据库体系方面的一些想法,在这里分享给大家,希望能够抛砖引玉。大家如果能够在我今天分享后,结合自己面对的实际场景,得到一些体会,有点想法的话,我今天分享的目的就达到了。
今天我会讲以下几方面内容:首先讲一下我们在内核上的一点创新、数据库怎么实现弹性调度、关于智能化的思考、最后是曾经踩过的坑和看到未来的方向。
首先说一下,阿里巴巴最早一代使用的数据库技术是Oracle,后面大家也知道一件事情就是去IOE,去IOE过程中我们迈向了使用开源数据库的时代,这个时代今天已经过去,这个过程大概持续了五六年,整个阿里巴巴有一个大家都知道的开源MYSQL分支--AliSQL,我们在上面做了大量的改进,所以我这里列了一下在AliSQL上的一些改进,但今天我实际上并不想讲这个,我想讲一下面向未来的下一代数据库技术、数据库架构会往哪个方向走。
我觉得是这样的,因为今天的阿里巴巴毕竟是一个技术的公司,所以很多时候我们会看比如说Google或者是一些互联网的大的公司,他们在技术上创新点来自于哪里?来自于问题。就是说今天在座的各位和我是一样的,你所面对场景下的问题是什么、你看问题深度如何决定了你今天创造的创新有多大。
所以今天我们重新看一下阿里面临的问题是什么,大家也能够看到自己所面临的问题是什么,你将如何思考。
可以看到其实阿里巴巴的应用和Facebook、Google的还是有很大区别的,我们也找他们做了交流,发现跟他们的业务场景真的不一样,首先我们的主要应用是交易型的,这些应用会有些什么要求,你会看到有这些点(见图片),下面主要讲一下我们的思考。
第一:今天数据的高可用和强一致是非常重要的,数据不一致带来的问题是非常非常巨大的,大家也用淘宝,也是阿里巴巴一些服务的用户,数据不一致带来的问题,每一个用户、甚至我的父母都会关注这些事情。
第二:今天存储成本是非常高的,所有的数据中心已经在用SSD,但数据的存储成本依然是一个大型企业面临的一个非常大的问题,这都是实实在在钱的问题。
另外刚才也提到了,数据都是有生命周期的,那么数据尤其是交易数据是有非常明显的冷和热的状态,大家一定很少看自己一年前在淘宝的购买记录,但是当下的购买记录会去看,那系统就需要经常会去读它、更新它。
还有一个特点是今天阿里的业务还是相对简单的,比如我们要在OLTP性能上做到极致性。还有一个阿里巴巴特有的点就是双十一,双十一本质上是什么,本质上就是制造了一个技术上非常大的热点效应。这对我们提出什么样的需求呢?需求就是一个极致弹性的能力,数据库实际上在这个方向是非常欠缺的,数据库怎么样去做到弹性伸缩是非常难的事情。
双11是一场技术大练兵,是互联网界的超级工程。需要做到支撑尽可能高的零点峰值,给用户最好的体验;也要做到成本尽可能低,要求极致的弹性能力;还要做到整体系统的稳定。
大家都知道,数据库实现弹性能力是比较困难的,一方面是因为数据库对性能要求非常高,另一方面是需要进行大量数据的搬迁,成本很高。数据库弹性的第一个方向是数据库上云,通过云的弹性能力来解决数据库的资源问题。
数据库上云面临以下几个难点:
1.数据库如何快速上云,构建混合云?
2.如何降低虚拟化带来的性能损耗?
3.公有云环境和内部网络的互通问题。
经过几年的探索,这些难点都已得到解决。
第一,数据库使用了高性能ECS,通过使用SPDK、DPDK技术和NVMe存储,可以让虚拟化损耗非常小,接近物理机;
第二,我们建设了一套数据库混合云管理系统,可以同时管理云上和云下环境,在双11前快速把混合云构建起来,支撑双十一。
第三,我们通过VPC网络连接阿里内部和公有云的网络,解决了混合云场景下的网络互联问题。
使用云的资源还不够,为了实现更加极致的弹性能力,我们通过离在线混部技术,可以让数据库使用离线集群的计算资源,最大程度的降低成本。为了实现离在线混部技术,有两大基础条件:第一是容器化,通过容器实现了计算节点的资源隔离和统一调度,第二是计算存储分离,它是数据库弹性调度能力的基础。非常幸运的是,这几年技术的发展让存储计算分离成为可能,比如:25G高速网络、RDMA技术,高性能分布式存储等。
数据库存储计算分离架构如图,包括存储层、网络层和计算层,存储使用阿里自研分布式存储系统-盘古,数据库计算节点则部署在阿里自研容器(Pouch)中,通过25G网络与存储节点连接。
为了实现数据库存储和计算分离,我们在分布式存储-盘古上做了非常多的优化,比如:
响应延时:单路读写响应延时0.4ms,RDMA网络响应延时小于0.2ms;
二三异步:第三个数据副本异步完成,极大提升了延时的稳定性;
QoS流控:根据前台业务负载情况控制后台IO流量,保证写入性能;
快速Failover:存储集群单机failover优化为5秒,达到业界领先水平;
高可用部署:单集群四Rack部署,将数据可靠性提升到10个9。
同时,在数据库方面我们也做了大量优化,最重要的是降低计算节点和存储节点的网络传输量,以此来降低网络延迟对于数据库性能的影响。第一是redo log sync优化,将数据库吞吐提升了100%。第二是由于盘古支持原子写功能,所以我们关闭了数据库的Double Write Buffer,高压力下数据库吞吐提升20%,网络带宽节省了100%。
容器化和存储计算分离,使得数据库无状态化,具备调度能力。在双11高峰,通过将共享存储挂载到不同的计算集群(离线集群),实现数据库的快速弹性。
阿里最早是商业数据库,然后我们做去IOE,研发出阿里MySQL分支AliSQL和分布式中间件TDDL。2016年,我们开始研发阿里新一代数据库技术,我们把它命名为X-DB,X代表追求极限性能,挑战无限可能的含义。
阿里的业务场景对于数据库有很高的要求:
因此,定义新一代数据库就要包含几个重要特点:具备数据强一致、全球部署能力;内置分布式、高性能、高可用能力;具备自动数据生命周期管理能力。
X-DB架构如图,引入Paxos分布式一致性协议解决问题;可异地部署,虽然网络延时增加,但能够保持高性能(吞吐),在同城三节点部署模式下,性能与单机持平,同时具备网络抖动的高容忍性。
X-DB核心技术之一:高性能Paxos基础库X-Paxos是实现三节点能力的核心,可实现跨AZ、Region的数据强一致能力,实现5个9以上的持续可用率。
X-DB核心技术之二:Batching & Pipelining。X-DB在事务提交时,必须保证日志在数据库节点的多数派收到并提交,这是保证数据强一致基础,由于事务在提交时必须需要跨网络,这一定会导致延时增加,要保证高延时下的吞吐是非常困难的。Batching & Pipelining技术保证尽可能批量提交,数据可以乱序接收和确认,最终保证日志顺序提交。可以在高延时的情况下,保持很高的吞吐能力。
X-DB核心技术之三:异步化提交,数据库线程池在提交时会等待,为了最大程度提升性能,我们采用了异步化提交技术,最大可能保证数据库线程池可以高效工作。通过这些技术保证X-DB在三节点模式下的高吞吐量。
我们与Oracle官方的Group Replication作对比。在三节点同IDC部署模式下,sysbench标准化测试。Insert场景,我们可以做到MySQL官方的2.4倍,响应时间比官方低。
在异地部署模式下,sysbench标准化测试。Insert场景,X-DB(5.04万)性能优势特别明显,是MySQL GR(0.85万)的5.94倍,响应延时X-DB(58ms)是MySQL GR(150ms)的38%。
同城跨AZ部署替代传统主备模式,我们把原来主备模式变成三节点,解决跨AZ数据质量问题和高可用问题。跨AZ数据强一致,单AZ不可用数据零丢失、单AZ不可用秒级切换、切换自封闭,无第三方组件。相对主备模式零成本增加。
跨Region部署,用更底层的数据库技术解决异地多活问题,三地六副本(主备模式)降低为三地五副本(三地五节点四数据),对于业务来说,可以享受跨Region数据强一致,单个Region不可用零数据丢失;跨Region强同步下依然保持高性能;切换策略灵活,可以优先切换同Region,也可定制跨Region切换顺序。
X-KV是基于官方MySQL Memcached plugin的增强,今年我们做了大幅度的改进,支持更多数据类型,支持非唯一索引、组合索引,multi get功能,还支持Online Schema change。最大变化是通过TDDL支持SQL转换。对于业务方,X-KV优势是超高读取性能,数据强一致,减少应用响应时间,降低了成本,同时因为支持SQL,应用可以透明迁移,使用成本大幅降低。
TDDLfor X-KV实现了如下功能:
独立的连接池:SQL和KV连接池相互独立;变更时,两套连接池保持协同一致;应用可以快速在两套接口之间切换。
优化的KV通信协议:不再需要分隔符,协议实现。
结果集自动类型转换:字符串自动转换为MySQL类型。
随着双11交易量增长,近两年交易买家库和卖家库的同步延时一直比较大,导致商户不能及时处理双11订单;且卖家库有大量复杂的查询,性能差。我们曾经通过为大卖家设置独立队列、同步链路合并操作和卖家库限流等进行优化,但仍然没有完全解决问题。
ESDB是基于ES打造的分布式文档数据库,我们在ElasticSearch的基础上,支持了SQL接口,应用可以从MySQL无缝迁移到ESDB;针对大卖家,提供动态二级散列功能,彻底解决了数据同步的性能瓶颈,而且ESDB还可以提供复杂的查询能力。
数据库监控系统的技术挑战具体有以下四点:
1.海量数据:平均每秒1000万项监控指标,峰值1400万;
2.复杂的聚合逻辑:地域、机房、单元、业务集群、数据库主备等多维度数据聚合;
3.实时性要求高:监控盯屏需要立即看到上一秒的监控数值;
4.计算资源:占用尽可能少的资源进行采集和计算。
整个链路经历三代架构:第一代Agent + MySQL;第二代Agent + datahub + 分布式NoSQL;第三代Agent + 实时计算引擎 + HiTSDB
HiTSDB是阿里自研的时序型数据库,非常适合存储海量的监控类数据。通过实时计算引擎将秒级性能数据、全量SQL运行状况进行预先处理后,存储在HiTSDB中。通过第三代架构,实现了双11高峰不降低的秒级监控能力,这对我们了解系统运行状况、诊断问题是非常有帮助的。
阿里拥有业界最富有经验的DBA,海量的性能诊断数据。我们的目标是把阿里DBA的经验、大数据和机器智能技术结合起来,目标是三年后不再需要DBA做数据库诊断、优化等工作,而是让机器来完成数据库的智能化管理。我们认为自诊断、自优化、自运维是未来数据库技术发展的重要方向。
CloudDBA在今年双11也做了一些探索,通过对全量SQL以及监控数据的分析,我们实现了SQL自动优化(慢SQL调优)、空间优化(无用表无用索引分析)、访问模型优化(SQL和KV)和存储空间增长预测等功能。
最后我用大白话讲一下我对整个数据库体系的一些理解。
今天在一个公司里边没有一个存储或者是数据库可以解决所有问题,今天越来越多的趋势看到,数据存储的多样性是必然会存在的,因为行存有行存的优势、列存有列存的优势、做计算有计算的优势、做分析有做分析的优势、做OLTP有OLTP的优势,不要指望,或者很难指望一个系统干所有的事情很,这个话我说了可能不太好,但是确实比较难,但是我们看到的一点是什么?
————就是每个技术或产品在生产中干一件事情可以干到最好,你就用它做的最好的那件事解你的问题就好了。
作者:JAVA架构师的圈子
链接:https://www.jianshu.com/p/f909545922ad
来源:简书