【Infra Meetup NO.54】数据库计算存储分离架构分析（内附视频）

上周六，PingCAP Infra Meetup 第 54 期，我们邀请到了知乎大 V 李凯（知乎 ID：郁白）为大家分享了《数据库计算存储分离架构分析》。在活动现场，郁白老师跟小伙伴们有一番深度的交流与思想碰撞。长话短说，小编带你一起回顾精彩现场。

精彩视频

精彩现场

PingCAP Infra Meetup 第 54 期的活动现场十分火爆，活动签到时间未开始，小伙伴们就早早来到现场占位置，我想说早来的小伙伴们还是很明智的。因为......

后续到场的小伙伴只能酱婶儿滴扎堆在门口竖起耳朵听了，这场活动简直是一场郁白大神与粉丝的见面会。

说了这么多，先上一张郁白老师的图吧~ ?  

上技术干货

大数据下公有云面临的 5 个挑战

谈到存储架构分离，为什么现在会有 Aurora 架构？包括前一阵阿里的 PolarDB 推出来以后，他们也在分析为什么要做这个东西。

郁白老师认为单就公有云来说，现在云数据面临的挑战有以下 5 个：

1、跨 AZ 的可用性与数据安全性。现在都提多 AZ 部署，亚马逊在全球有 40 多个 AZ ，16 个 Region，基本上每一个 Region 之内的那些关键服务都是跨 3 个 AZ 。你要考虑整个 AZ 意外宕机或者计划内维护要怎么处理，数据迁移恢复速度怎么样。以传统的 MySQL 为例，比如说一个机器坏了，可能这个机器上存了几十 T、上百 T 的数据，那么即使在万兆网卡的情况下，也要拷个几分钟或者几十分钟都有可能。那么有没有可能加快这个速度。

还有一个就是服务恢复的速度。可能大家广为诟病就是基于 MySQL Binlog 复制。在主机压力非常大的情况下，是有可能在切换到备机以后，这个备机恢复可能需要几分钟甚至几十分钟。关键因素是回放 Binlog 的效率，MySQL 即使最新版本也只能做到 Group Commit 内的并发回放。这是数据库 RTO 指标，能不能在秒级、分钟级把这个服务恢复起来，这是一个在设计系统的时候要考虑的关键问题。

2、读写分离与弹性扩展。一般来说我们讲云上数据库基本上都是集中化的，一写多读的，那这里会涉及到读写分离，把主库上一致性要求不高的读流量分给备库，这种情况下读写分离的备库能不能弹性扩展？我们知道 MySQL 可以通过 Binlog 复制来扩展备机，但是扩展的过程中就意味着复制一份完整数据，就像我们刚才提到的数据恢复一样，他要把整个数据全部复制过去然后把 Binlog 接上，这个时间可能你要真做的话几十分钟就过去了。如果说你的业务真撑不住说我赶快要加备机，那这个东西怎么去解决？

3、资源的按需分配。这点其实云计算上的云数据库一定程度上已经做到了，当然有些可能不一样，比如说有硬件独享的数据库就很难做到按需分配。像阿里可能会把 EBS 接到它的数据库虚拟机上，这样的话其实你接上了弹性化存储以后也基本上做到一个弹性的分配，要 1G 给 1G ，再要 1G 再给 1G ，不说一开始就把资源分配了，这是云上的一个弹性的东西。

4、高性能。现在大家都要看跑分，除了跑分，还要看跑实际业务的时候到底行不行，有没有办法去优化。

5、生态兼容性。比如说为什么 TiDB 一定要做 MySQL 的兼容？我觉得可能也是考虑这一点，现在开源领域最强的生态可能还是 MySQL，开源的数据库如果不做 MySQL 兼容，别人可能不一定会来用。

从以上这几点出发的话，我们就可以考虑一个云数据库到底怎么去发展。

AWS Aurora 的架构特点及优势

计算存储分离架构的 4 个关键技术

点击【阅读原文】即可下载完整版 PPT ✌️

PingCAP Infra Meetup

作为一个基础架构领域的前沿技术公司，PingCAP 希望能为国内真正关注技术本身的 Hackers 打造一个自由分享的平台。自 2016 年 3 月 5 日开始，我们定期在周六的上午举办 Infra Meetup，邀请业内大牛与大家深度探讨基础架构领域的前瞻性技术思考与经验。在这里，我们希望提供一个高水准的前沿技术讨论空间，让大家真正感受到自由的开源精神魅力。

长按关注

新型分布式 NewSQL 数据库

微信号：pingcap2015