Amazon Aurora

Amazon Aurora 是与 MySQL 兼容的关系数据库引擎,既具备高端商用数据库的速度和可用性,又有开源数据库的简单性和成本效益。Amazon Aurora 的性能最高可达到 MySQL 的五倍,并且能以十分之一的成本提供商用数据库的安全性、可用性和可靠性。

2015 年,Amazon Aurora 发布,提供了 5x 于单机 MySQL 5.6 的读吞吐能力,不过最大也就扩展到 15 个副本,副本越多对写吞吐影响越大,因为只有一个 Primary Instance 能提供写入服务,单个副本最大支持容量 64T,而且支持高可用以及弹性的扩展。值得一提的是 Aurora 的兼容性。其实做数据库的都知道,兼容性是一个很难解决的问题,可能实现上很小的差异就会让用户的迁移成本变得很大,这也是为什么中间件和分库分表的方案如此反人类的原因,我们大多都在追求用户平滑的迁移体验。

Aurora 另辟蹊径,由于公开的资料不多,我猜想 Aurora 在 MySQL 前端之下实现了一个基于 InnoDB 的分布式共享存储层(https://www.percona.com/blog/2015/11/16/amazon-aurora-looking-deeper/)。对于读实例来说是很好水平扩展的,这样就将 workload 均摊在前端的各个 MySQL 实例上,有点类似 Oracle RAC 那样的 Share everything 的架构。

这个架构的好处相对中间件的方案很明显,兼容性更强,因为还是复用了 MySQL 的 SQL 解析器。优化器,业务层即使有复杂查询也没关系,因为连接的就是 MySQL。

但是也正是由于这个原因,在节点更多,数据量更大的情况下,查询并不能利用集群的计算能力(对于很多复杂查询来说,瓶颈出现在 CPU 上),而且 MySQL 的 SQL 优化器能力一直是 MySQL 的弱项,而且对于大数据量的查询的 SQL 引擎的设计是和单机有天壤之别的。一个简单的例子,分布式 Query Engine 比如 SparkSQL / Presto / Impala 的设计肯定和单机的 SQL 优化器完全不同,更像是一个分布式计算框架。

所以我认为 Aurora 是一个在数据量不太大的情况下(有容量上限),对简单查询的读性能优化的方案,另外兼容性比中间件的方案好得多。但是缺点是对于大数据量,复杂查询的支持还是比较弱,另外对于写入性能 Aurora 其实没有做太多优化(单点写入),如果写入上出现瓶颈,仍然需要在业务层做水平或者竖直拆分。

链接