2017双11技术揭秘—阿里数据库计算存储分离与离在线混布

本文涉及的产品
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
性能测试 PTS,5000VUM额度
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 随着阿里集团电商、物流、大文娱等业务的蓬勃发展,数据库实例以及数据存储规模不断增长,在传统基于单机的运维以及管理模式下,遇到诸多如成本,调度效率等问题,因此,2017年首次对数据库实现计算存储分离,计算存储分离后,再将计算节点与离线资源混布,达到节省大促成本的目的。

作者:吕建枢(吕健)

背景

随着阿里集团电商、物流、大文娱等业务的蓬勃发展,数据库实例以及数据存储规模不断增长,在传统基于单机的运维以及管理模式下,遇到非常多的困难与挑战,主要归结为:

  1. 机型采购与预算问题
    在单机模式下计算资源(CPU和内存)与存储资源(主要为磁盘或者SSD)存在着不可调和的冲突;计算与存储资源绑定紧密,无法进行单独预算。数据库存储时,要么计算资源达到瓶颈,要么是存储单机存储容量不足。这种绑定模式下,注定了有一种资源必须是浪费的。
  2. 调度效率问题
    在计算与存储绑定的情况下,计算资源无法做无状态调度,导致无法实现大规模低成本调度,也就无法与在大促与离线资源进行混布。
  3. 大促成本问题
    在计算资源无法做到调度后,离线混布就不再可能;为了大促需要采购更多的机器,大促成本上涨严重。

因此,为了解决诸多如成本,调度效率等问题,2017年首次对数据库实现计算存储分离;计算存储分离后,再将计算节点与离线资源混布,达到节省大促成本的目的。

2017年数据库计算存储分离,

使得数据库进行大规模无状态化容器调度成为可能!

使得数据库与离线业务混布成为可能!

使得低成本支持大促弹性成为可能!

在高吞吐下,总存储集群整体RT表现平稳,与离线资源联合首次发力,完成2017年“11.11”大促的交易支撑。

计算存储分离

在所有业务中,数据库的计算存储分离最难,这是大家公认的。因为数据库对于存储的稳定性以及单路端到端的时延有着极致的要求:

存储稳定性

在分布式存储的稳定性方面,我们做了非常多的有意探索,并且逐一落地。这些新技术的落地,使得数据库计算存储分离成为可能:

单机failover

单机failover我们做到业界的极致,5s内完成fo,对整体集群的影响在4%以内(以集群规模24台为例,集群机器越多,影响越小)。另外,我们对分布式存储的状态机进行加速优化,使得基于paxos的选举在秒级内进行集群视图更新推送。

长尾时延优化

计算存储分离后,所有的IO都变成了网络IO,因此对于单路IO时延影响的因素非常多,如网络抖动,慢盘,负载等,而这些因素也是不可避免的。我们设计了“副本达成多数写入即返回的策略(commit majority feature)”,能够有效地使长尾时延抖动做到合理的控制,以满足业务的需求。

以下是commit majority feature开起前后的效果对比。其中“蓝色”为优化后的长尾时延,“红色”为优化前长尾时延,效果非常显著。

流控

我们实现了基于滑动窗口的流控功能,使得集群后台活动(如backfill和recovery)能根据当前的业务流量进行自适配的调整,在业务与后台数据恢复之间做到最佳平衡。

一般如果集群后端活动太低,会影响数据恢复,这会提高多盘故障的概率,降低了数据的可靠性。我们经过优化后,通过滑动窗口机制,做到了前后端数据写入的速动,在不影响业务写入的情况下,尽最大可能提高数据恢复速度,保证多副本数据的完整性。

提高数据重平衡的速度,也是为了保证整个集群的性能。因为一出现数据倾斜时,部分盘的负载将变大,从而会影响整个集群的时延和吞吐。
流控效果如下:

高可用部署

在高可用部署上,我们引入的故障域的概念。多个数据副本存储在多个故障域,分布到至少4个RACK以上的机架上,用于保障底层机柜电源以及网络交换设备引起的故障等。

为了能够更好的理解数据副本存储位置(data locality),需要知道数据散射度(scatter width)的概念。怎么来理解数据散射度?

举个例子:我们定义三个copy set(存放的都是不同的数据):{1,2,3},{4,5,6},{7,8,9}。任意一组copy set中存放的数据没有重复,也就是说一份数据的三个副本分别放置在:{1,4,7}或者{2,5,8}或者{3,6,9}。那么这个时候,其数据散射度远小于随机组合的C(9,3)。

随机组合时,任意3台机器Down机都会存在数据丢失。而采用此方案后,只有当{1,4,7}或者{2,5,8}或者{3,6,9}其中的任意一个组合不可用时,才会影响高可用性,才会有数据丢失。

综上可知,我们引入copy set的目标就是尽量的降低数据散射度“S”。下图中两组replica set,其中每一组的三个副本分别放置到不同的RACK中。

我们的优化还有很多,这里不再一一列举。

数据库吞吐优化

当所有的IO都变成网络IO后,我们要做的就是如何减少单路IO的延迟,当然这个是分布式存储以及网络要解的问题。

分布式存储需要优化自身的软件stack以及底层SPDK的结合等。

而网络层则需要更高带宽以及低时延技术,如25G TCP或者25G RDMA,或者100G等更高带宽的网络等。

但是我们可以从另外一个角度来考虑问题,如何在时延一定的情况下,提高并发量,从而来提高吞吐。或者说在关键路径上减少IO调用的次数,从而从某种程度上提高系统的吞吐。

大家知道,影响数据库事务数的最关键因素就是事务commit的速度,commit的速度依赖于写REDO时的IO吞吐。所谓的REDO也就是大家熟知的WAL(Write Ahead Log)日志。

在脏数据flush回存储时,日志必须先落地,这是因为数据库的Crash Recovery是重度以来于此的。在recovery阶段,数据库先利用redo进行roll forward,再利用undo进行roll backward,最后再撤销用户未提交的事务。

因此,存储计算分离下,要想在单路IO时延一定时提高吞吐,就必须要优化commit提交时的效率。我们通过优化redo的写入方式,让整个提高吞吐100%左右。另外,也可以优化redo group commit的大小,结合底层存储stripe能力,做并发与吞吐优化。

数据库原子写

在数据库内存模型中,数据页通常是以16K做为一个bufferpage来管理的。当内核修改完数据之后,会有专门的“checkpoint”线程按一定的频率将Dirty Page flush到磁盘上。我们知道,通常os的page cache是4K,而一般的文件系统block size也是4K。所以一个16k和page会被分成4个4k的os filesystem block size来存储,物理上不能保证连续性。

那么会带来一个严重的问题,就是当fsync语义发出时,一个16k的pageflush,只完成其中的8k,而这个时候client端crash,不再会有重试;那么整个fsync就只写了一半,fsync语义被破坏,数据不完整。上面的这个场景,我们称之为“partial write”。

对于MySQL而言,在本地存储时,使用Double Write Buffer问题不大。但是如果底层变成网络IO,IO时延变高时,会使MySQL的整体吞吐下降,而Double Write Buffer会加重这个影响。

我们实现了原子写,关闭掉Double Write Buffer,从而在高并发压力及高网络IO时延下,让吞吐至少提高50%以上。

网络架构升级

分布式存储,对于网络的带宽要求极高,我们引入了25G网络。高带宽能更好的支持阿里集团的大促业务。另外,对于存储集群后台的活动,如数据重平衡以及恢复都提供了有力的保障。

离在线混布

计算存储分离后,离在线混布成为可能;今年完成数据库离在线混布,为2017年大促节省了计算资源成本。

在与离线混布的方案中,我们对数据库与离线任务混跑的场景进行了大量的测试。

实践证明,数据库对时延极度敏感,所以为了达到数据库混布的目的,我们采用了以下的隔离方案:

CPU与内存隔离技术

CPU的L3是被各个核共享的,如果在一个socket内部进行调度,会对数据库业务有抖动。因此,在大促场景下,我们会对CPU进行独立socket 绑定,避免L3 cache干扰;另外,内存不超卖。当然,大促结束后,在业务平峰时,可以择机进行调度和超卖。

网络QOS

我们对数据库在线业务进行网络打标,NetQoS中将数据库计算节点的所有通信组件加入到高优先级group中。

基于分布式存储的弹性效率

基于分布式存储,底层分布式存储支持多点mount,用于将计算节点快速弹性到离线机器。

另外,数据库Buffer Pool可以进行动态扩容。大促ODPS任务撤离,DB实例Buffer Pool扩容;大促结束后,Buffer Pool回缩到平峰业务时的大小。

双11大促求证

大促期间,其中一个库吞吐达到将近3w tps,RT在1ms以内,基本上与本地相当,很好的支撑了2017年大促。这就是我们今年所做的诸多技术创新的结果。

展望

目前我们正在进行软硬件结合(RDMA,SPDK)以及上层数据库引擎与分布式存储融合优化,性能将会超出传统SATA SSD本地盘的性能。

RDMA和SPDK的特点就是kernel pass-by。未来,我们数据库将引入全用户态IO Stack,从计算节点到存储节点使用用户态技术,更能充分满足集团电商业务对高吞吐低时延的极致要求。

这些网络和硬件技术的发展,将会给“云计算”带来更多的可能性,也会给真正的“云计算”新的商业模式带来更多憧憬,而我们已经在这条阳光的大道上。

欢迎有更多的存储及数据库内核专家一起参与进来,一起携手迈进未来。

【引用】

[1] Copysets:Reducing the Frequency of Data Loss in Cloud Storage

[2] CRUSH: Controlled,Scalable, Decentralized Placement of Replicated Data

相关文章
|
12天前
|
SQL 存储 关系型数据库
【SQL技术】不同数据库引擎 SQL 优化方案剖析
不同数据库系统(MySQL、PostgreSQL、Doris、Hive)的SQL优化策略。存储引擎特点、SQL执行流程及常见操作(如条件查询、排序、聚合函数)的优化方法。针对各数据库,索引使用、分区裁剪、谓词下推等技术,并提供了具体的SQL示例。通用的SQL调优技巧,如避免使用`COUNT(DISTINCT)`、减少小文件问题、慎重使用`SELECT *`等。通过合理选择和应用这些优化策略,可以显著提升数据库查询性能和系统稳定性。
69 9
|
1月前
|
存储 运维 OLAP
【Meetup回顾 第1期】竟是这样的国产数据库,YashanDB技术内幕曝光
YashanDB是一款基于统一内核,支持单机/主备、共享集群、分布式等多种部署方式,覆盖OLTP/HTAP/OLAP交易和分析混合负载场景的新型数据库系统;YashanDB同时提供开发平台、运维平台和迁移平台3大工具平台以满足数据全生命周期管理。
35 2
【Meetup回顾 第1期】竟是这样的国产数据库,YashanDB技术内幕曝光
|
1月前
|
关系型数据库 分布式数据库 数据库
1月17日|阿里云云谷园区,PolarDB V2.0技术沙龙,畅聊国产数据库
为了助力国产化项目顺利推进,阿里云邀请企业开发者和数据库负责人到云谷园区,与PolarDB V2.0技术专家面对面交流。扫描海报二维码报名,我们将根据信息为您申请入园。欢迎参与,共同探讨PolarDB的最新技术和应用!
|
2月前
|
人工智能 物联网 大数据
解密时序数据库的未来:TDengine Open Day技术沙龙精彩回顾
在数字化时代,开源已成为推动技术创新和知识共享的核心力量,尤其在数据领域,开源技术的涌现不仅促进了行业的快速发展,也让更多的开发者和技术爱好者得以参与其中。随着物联网、工业互联网等技术的广泛应用,时序数据库的需求愈发强烈,开源的兴起更是为这一技术的创新与普及提供了强有力的支持。
46 3
|
2月前
|
存储 JSON NoSQL
学习 MongoDB:打开强大的数据库技术大门
MongoDB 是一个基于分布式文件存储的文档数据库,由 C++ 编写,旨在为 Web 应用提供可扩展的高性能数据存储解决方案。它与 MySQL 类似,但使用文档结构而非表结构。核心概念包括:数据库(Database)、集合(Collection)、文档(Document)和字段(Field)。MongoDB 使用 BSON 格式存储数据,支持多种数据类型,如字符串、整数、数组等,并通过二进制编码实现高效存储和传输。BSON 文档结构类似 JSON,但更紧凑,适合网络传输。
82 15
|
2月前
|
存储 druid 分布式数据库
列式存储数据库与超市的关系?
列式存储数据库是一种高效的数据管理方式,类似于超市将相似商品集中摆放。它将相同类型的数据(如年龄、价格)归类存储,便于快速查询和压缩,广泛应用于市场分析、财务报告和健康数据分析等领域。知名产品包括HBase、ClickHouse、Druid和Apache Cassandra等,适合处理大规模数据和实时分析任务。
45 4
|
3月前
|
存储 数据库
快速搭建南大通用GBase 8s数据库SSC共享存储集群
本文介绍如何GBase8s 数据库 在单机环境中快速部署SSC共享存储集群,涵盖准备工作、安装数据库、创建环境变量文件、准备数据存储目录、修改sqlhost、设置onconfig、搭建sds集群及集群检查等步骤,助你轻松完成集群功能验证。
|
2月前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
26天前
|
关系型数据库 MySQL 数据库连接
数据库连接工具连接mysql提示:“Host ‘172.23.0.1‘ is not allowed to connect to this MySQL server“
docker-compose部署mysql8服务后,连接时提示不允许连接问题解决
|
13天前
|
关系型数据库 MySQL 数据库
Docker Compose V2 安装常用数据库MySQL+Mongo
以上内容涵盖了使用 Docker Compose 安装和管理 MySQL 和 MongoDB 的详细步骤,希望对您有所帮助。
91 42

热门文章

最新文章