加入收藏 | 设为首页 | 会员中心 | 我要投稿 惠州站长网 (https://www.0752zz.com.cn/)- 办公协同、云通信、物联设备、操作系统、高性能计算!
当前位置: 首页 > 建站 > 正文

阿里数据库的极致弹性之路

发布时间:2018-12-22 01:13:44 所属栏目:建站 来源:技术小能手
导读:副标题#e# 数据库从IOE(IBM小机、Oracle商业DB、EMC存储)一路走来,大家都知道数据库是资源重依赖的软件,对服务器的三大件CPU、内存、磁盘几乎都有要求。数据库作为广泛使用的数据存储系统,其SQL请求背后涉及的物理读、逻辑读、排序过滤等消耗了IO和CPU资

数据库的Share Nothing分布式扩展已经深入人心,存储计算分离会不会回到IOE状态?如果IDC是一个数据中心,应用就是计算,DB就是存储,DB自己再做存储计算分离有意义吗?数据是主备双副本的,存储计算分离后变成三副本,存储集群的容量池化能balance掉额外副本的成本吗?

为此我开始测算存储计算分离架构在大促场景下的投入产出,我们来看下大促场景,弹性大促时,业务需求计算能力数倍甚至10倍以上扩容,承担大促峰值压力,而磁盘因为存储长期数据,峰值的数据量在整体占比不高,因此磁盘容量基本不需要扩容。

在以前本地磁盘跑主备的架构,无法计算、存储分开扩容,大促指标越高,添加标准机器越多,成本浪费越大,因为磁盘是标准数据库机器的主要成本。而存储计算分离的情况下,测算下来,我们看到在较低日常压力下存储计算分离成本是比本地盘高的,但再往上,存储计算分离只需要增加计算,存储集群因为池化后,不只容量池化了,性能也池化了,任何高负载实例的IO都是打散到整个集群分担的,磁盘吞吐和IOPS复用,不需扩性能,成本优势非常明显。

磁盘不扩容,只扩计算自然成本低很多。传统的思考是存储集群容量池化的优势,但在大促场景我们更多用到的是性能的池化,突破单机瓶颈,因此我们提出了电商异地多活所有单元存储计算分离,其余业务继续使用本地磁盘进行同城容灾的目标架构。

提出这个设想,而这个架构的可行性如何判断?基于一些数字就可以推断,大家知道SSD磁盘的读写响应时间在100-200微秒,而16k的网络传输在10微秒内,因此尽管存储计算分离增加两到三次的网络交互,加上存储软件本身的消耗,整体有机会做到读写延时在 500微秒的范围内。在数据库实例压测中我们发现,随着并发增加,存储集群具备更大的QPS水位上线,这印证了性能池化突破单机瓶颈带来的吞吐提升。

数据库团队在2017年开始验证存储计算分离,基于25G的TCP网络实现存储计算分离部署,当年就承担了10%大促流量。我们基于分布式存储做到了700微秒的响应时间,这里内核态和软件栈的消耗较大,为此X-DB也针对性地做了慢IO优化,特别是日志刷盘的优化,开启原子写去掉了double write buffer提升吞吐能力。

这个过程中,我们沉淀了存储的资源调度系统,目前已经作为统一调度的组件服务集团业务。我们对当前架构性能不太满意,有了X-DB的慢IO优化、存储计算分离跨网络的IO路径、存储资源调度等技术沉淀,加上阿里巴巴RDMA网络架构的发展,2017下半年数据库开始和盘古团队一起,做端到端全用户态的存储计算分离方案。

四、全用户态IO链路的存储计算分离架构落地

阿里数据库的极致弹性之路

从数据库软件X-DB的IO调用开始,就走我们自己研发的用户态文件系统DBFS,DBFS使用盘古的用户态客户端,直接通过RDMA网络访问后端盘古分布式文件系统,整个IO链路完全绕过了内核栈。这里DBFS绕过了内核文件系统,自然也绕过了pagecache,为此DBFS针对数据库场景,实现了更简洁高效的BufferIO机制。

因为IO都是跨网络远程访问,因此RDMA起到了重要作用,以下是RDMA与TCP网络在不同包大小下的延时对比,除了延时优势外,RDMA对长尾IO的tail latency能够有效控制,对一个数据库请求涉及多次IO来说,对用户请求的响应时间能够更有效保证。RDMA技术的应用是DB大规模存储计算分离的前提条件,通过我们的数据实测,DBFS+RDMA链路的延时已经和Ext4+本地盘达到相同水平。

阿里数据库的极致弹性之路

(编辑:惠州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读