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

数据库的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+本地盘达到相同水平。

（编辑：惠州站长网）

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