Amazon Aurora介绍

发表于 | 分类于 |

Amazon 发布了旗下的Aurora数据库，兼容MySQL，号称5倍性能于MySQL

到底如何，来一探究竟

目录

  1. 官方介绍

  2. 宣传特点

  3. 概念与架构

  4. 性能、HA探讨

  5. 质疑、亮点

  6. 结论

  7. 参考文档

官方介绍

  • Amazon Aurora 是一个关系型数据库引擎，结合了高端商用数据库的速度和可用性，同时还具有开源数据库的简单性和成本效益

  • 它提供的吞吐量比同一硬件上运行的标准 MySQL 最多高出五倍。Amazon Aurora 的设计与 MySQL 5.6 兼容，因此现有 MySQL 应用程序和工具无需修改即可运行

  • Amazon Aurora 继 MySQL、Oracle、Microsoft SQL Server 和 PostgreSQL 之后，成为第五个可通过 Amazon RDS 提供给客户的数据库引擎

  • 兼容 MySQL 的关系数据库，其性能高达 MySQL 的 5 倍。有商业数据库的安全性、可用性和可靠性，但成本只是商业数据库的 1/10

  • 最高可以实现每秒 50 万次读取和 10 万次写入

  • 最多15个副本 存储空间最小为 10GB，最大为 64TB

  • Amazon Aurora 的设计旨在提供高于 99.99% 的可用性。从物理存储故障恢复是一个透明过程，而实例故障转移也只需要不到 30 秒

  • Amazon Aurora 的存储具有容错和自我修复功能。您的数据有六个副本复制分布在三个可用区中，并且会持续备份到 Amazon S3

宣传特点

  • 读写分离
  • 快速Fail Over
  • 从库几乎0延迟
  • 5X 性能于MySQL
  • 易于扩展（读）

概念与架构

  • Aurora 并不开源
  • Aurora 不是用于MySQL的插件式引擎（不是InnoDB或者TokuDB这样的引擎）
  • Aurora 算是一个数据库软件（网上都称其为engine，个人觉得，Aurora 作为一个软件更合适）
  • Aurora 是结合了Amazon 云生态系统里各种服务组件的、一个能够媲美商业数据库（官方宣传）的、兼容MySQL的数据库引擎
  • Aurora 开源了也没用，因为它依赖的都是Amazon自己的基础服务（S3等）

架构猜想

https://www.percona.com/blog/2015/11/16/amazon-aurora-looking-deeper/

  • 上图是Percona Vadim Tkachenko 猜想Aurora 的架构图，基本的原理就是共享了一个高效的存储层，用这种方式来取代binlog的复制方式，所以才会提供很快的Fail Over特性、几乎为0的从库延迟。

  • 这种架构，跟Oracle RAC 是不是很像？

  • PXC是不是也有些类似？Mariadb Galera
  • share everything？

ps：
Amazon 的工程师，在对外宣讲的一个点，就是针对现有数据库架构很多冗余部件的吐槽，这样对于数据的备份、成本、灵活性都很不方便。

吐槽

通过上述的这种架构，Aurora 可以：

  • Avoid data writes to storage??
  • Avoid binary logs
  • Avoid InnoDB transactional logs??
  • Disable doublewrites
  • Disable InnoDB checksums

理论上是有性能提升的。

官方架构图

  • 主实例
    • 支持读写工作负载，并执行针对集群卷的所有数据修改。每个 Aurora 数据库集群均有一个主实例
  • Aurora副本
    • 支持只读操作。每个数据库集群可拥有一个支持读写工作负载的主实例，以及最多 15 Aurora 个副本。多个 Aurora 副本将分配读取工作负载，您还可通过将 Aurora 副本置于单独的可用区中来提高数据库可用性
  • 存储
    • SSD 单一虚拟卷
    • 一个区域中的多个可用区的数据副本组成
    • 64 TB
  • 复制
    • 可以使用 MySQL 二进制日志 (binlog) 复制在两个 Amazon Aurora 数据库集群之间设置复制
  • 可靠性
    • 增加副本
    • 副本在不同可用区（类似IDC）
    • 存储自动修复
    • “自动恢复”缓存预热
    • 崩溃恢复
      • Aurora 设计为在发生崩溃时立即恢复并继续提供应用程序数据。Aurora 以异步方式对并行线程执行崩溃恢复，以便数据库在发生崩溃后打开并立即可用
  • 性能增强
    • 快速插入，特别适用于 LOAD DATA 和 INSERT INTO … SELECT … 语句
  • 安全性

性能 & HA

官方测试有争议

  • 官方宣称，写方面，3X 于MySQL，读方面，5X 于MySQL
  • 官方的测试环境
    • 250 tables, with 25000 rows each
    • 4.5GB
    • Amazon used r3.8xlarge instances
      • 32 virtual CPUs
      • 244GB of memory

性能测试1（Percona）

  • 结论
    • 在高配（高IO）的EC2机器上，Percona Server性能依然高于或者持平 Aurora。
    • 但是在数据量比较大的情况下，Aurora 还是有一定优势的。
    • 数据量较少的情况下，Aurora 性能不及Percona。如果按照官方的对比，Percona Server 也要比MySQL 高出很多性能了。
    • 最高IO的EC2，价格也最贵，成本最大。
    • 从下面的表格来看，Aurora 还是有一定的优势的。

价格对比：

Item Config Price a Year($)
Aurora 4 virtual CPUS + 30GB memory + 400GB 311.40
ps 4 virtual CPUS + 30GB memory + 500GB + 1500/3000 ios 210.60
ps-io2000 4 virtual CPUS + 30GB memory + 500GB + 2000 ios 353.10
ps-io3000 4 virtual CPUS + 30GB memory + 500GB + 3000 ios 418.10

性能测试2

  • 结论
    • 5X 太夸张
    • 性能好于用户自己在EC2上搭建的MySQL（跟percona的测试有冲突）
    • 跟自家的5.6 RDS比，没有太大优势
    • 但是Aurora 在响应时间上，有一定优势

HA测试

  • 上图来自Percona 工程师 Yves Trudeau
  • 图中显示，Aurora 的Fail Over速度明显好于MHA，但是跟Galera 还有差距
  • 该blog 从HA、性能等方面，大量对比了Galera 和Aurora，对于Aurora这种架构，只跟MySQL 单机去比，可能不太合适，和Galera 去对比，算是恰如其分的。

质疑 & 亮点

质疑

  • 5X 的性能，见上文。

  • 与官方MySQL比：

    • 大量细节（版本号标定、Bug List）显示，Aurora 跟MySQL 5.6 有很多渊源，并且，从Bug List 来看，Aurora 明显跟不上MySQL 官方的脚步，：

      My question here, does Amazon have the ability to keep up with MySQL bug fixes and regularly update their software? So far it does not seem so.

    • Amazon Aurora – Looking Deeper

  • unusual behaviour

    • 怪异的隔离级别

      • 默认只支持RR，修改其他不生效，但是不报错

    • 被杀掉的从库查询:

      Scenario:
      READER:
      execute long SELECT col1 FROM tab1
      WRITER:
      while SELECT running, execute ALTER TABLE tab1 ADD COLUMN col2 ;
      Effect: SELECT on READER fails immediately with an error: “ERROR 1866 (HY000): Query execution was interrupted on a read-only database because of a metadata change on the master”

      So there again I think Aurora does its best given architectural limitations and one-directional communication: it just chooses to kill read statements on Readers.

亮点

  • 修复了Query cache 对写造成的影响。

结论

  • 大神 DimitriK 表示一脸不屑，5.7早就可以达到100w QPS，单纯从性能来讲，Aurora 没有太大优势（官方宣称是50w Select QPS）。
    注释：Dim的测试全都是内存测试，他的原则就是这种最为简单的测试，最能体现引擎内部的性能极限。
    MySQL Performance: 5.7 and RDS Aurora, so what?.. ;-)
  • 个人认为，单纯讨论性能没有太大意义，要从RDS服务本身去谈。如备份、高可用。
  • Aurora 的设计利用了Amazon 本身的诸多系统，从设计本身就可以做到高速Fail Over，另外，其备份也要比传统的MySQL实例备份来的方便。
  • 从Amazon 方面考虑，开发Aurora 这种东西，利用了自家的很多技术，这对云服务的成本来讲也是很大一笔节约。
  • 对用户来讲，购买EC2 主机来搭建MySQL也许不是一个明智的选择，如果Amazon 能提供更好、更廉价的RDS服务，何乐而不为？
  • Amazon 的野心，在于构建一个能够媲美商业数据库的数据库，但是这个数据库并不是一个用来卖的软件（像Oracle那样），他的目的在于打造一个基于云的商业数据库服务，及Amazon RDS。
  • 套用Percona Vadim Tkachenko 的一句话：

In general I think Amazon Aurora is a quite advanced proprietary version of MySQL. It is not revolutionary, however, and indeed not “reimagined relational databases” as Amazon presents it. This technology does not address a problem with scaling writes, sharding and does not handle cross-nodes transactions.

“这不是一个革命性的产品，它没能解决写扩展的问题，也没有解决sharding、以及多节点事物的问题，但是这给关系型数据库未来的发展，提供了一些想象，是一个很好的MySQL衍生品。”

参考文档

重点推荐

Update

  • 如果用MySQL跑在Docker里，底层跑一个Ceph分布式存储，是不是跟上面的有点类似呢？
    • Docker用来做快速切换
    • Ceph做底层的分布式存储，确保数据永远不丢，且方便做文件快照

热评文章