Aurora, Mysql, Redshift 应用场景和成本分析

Amazon Aurora 作为 AWS 增长最快的服务，已经在中国宁夏区域可用。越来越多的客户选择 Aurora 作为核心关系型数据库，处理核心数据业务。除了 Aurora 之外， AWS 还提供了RDS Mysql等数据库引擎，供客户选择。另外，AWS 还有 Amazon Redshift 数据仓库产品，作为海量大数据分析使用。

那么，如何选择合适的产品，来满足自己的业务需求呢？接下来我们会从技术和成本方面，详细分析Aurora/Mysql/Redshift这三款产品。

性能

Aurora 日志即数据库+计算存储分离的设计理念，使得Aurora拥有相比传统数据库更高的性能表现。

以下是AWS数据库专家使用Sysbench工具对Aurora和Mysql 5.6分别进行压力测试的结果。实例类型r4.8xlarge(32 vCPU, 244GB内存)。

https://aws.amazon.com/cn/blogs/china/aurora-test/

只读负载

读/写混合负载

可以明显看到Aurora相比Mysql，无论在QPS/TPS，还是在响应时间上，都有巨大的优势。从并发连接数来看，随着并发数的增加，这个优势会更加明显。当Mysql并发数大于1000时，由于资源争用，QPS/TPS急剧下降。而Aurora虽然略有下降，但是仍然能保持相对平稳的水平。当并发数到达6000时，Aurora 659K vs Mysql 8.9K，QPS的差距就更大了。

并发量巨大时，Mysql已经支撑不住业务压力，再如何加机器，或者提升机型，都效果不好。此时通常的做法，是分库分表。此方式能暂时减缓压力，但是引入了更复杂的中间件，加大了管理难度。Aurora在高并发时的优异表现，完全能承载压力，而无需分库分表。

典型的场景，适用于金融、电信等大量在线交易。客户包括Dow Jones、Capital One、Verizon、NTT DOCOMO、Netflix等等。

这只是普通的测试。现在Aurora Mysql 5.6加入了并行查询的支持，利用底层存储节点的计算能力，进行并行计算，大幅提升查询速度。参考：

https://aws.amazon.com/blogs/aws/new-parallel-query-for-amazon-aurora/

Aurora的优势，在大并发的场景下表现得淋漓尽致。那么，是否所有场景都适合Aurora呢？

在频繁更新的业务场景下，如果Innodb表添加了二级索引，并且禁用了change buffer，那么由于没有索引写缓存，直接写入磁盘会极大影响性能。Aurora和Mysql都会受到此影响。在此场景下，Aurora对于Mysql，优势不再明显。

请记住：Aurora也是SQL关系型数据库，传统数据库的优化机制，包括索引、缓存、SQL等，仍然适用。良好的表设计和SQL优化，仍然是DBA需要考虑的问题。

在单个读写的请求表现上，Aurora并不对Mysql有优势。在没有压力的情况下，一个简单的SELECT查询，Aurora和Mysql，响应时间可能很接近。

以下是在一张千万行的表上，Aurora和Mysql的查询响应时间对比。

Aurora:

mysql> mysql> select count(*) from user_test where create_time between ‘2013-01-01 00:00:00’ and ‘2015-01-01 00:00:00’ and age =31;

+———-+

| count(*) |

+———-+

|    60633 |

+———-+

1 row in set (2.80 sec)

Mysql:

mysql> select count(*) from user_test where create_time between ‘2013-01-01 00:00:00’ and ‘201500:00:00’ and age =31;

+———-+

| count(*) |

+———-+

|    60633 |

+———-+

1 row in set (2.51 sec)

可以看到，响应时间上，Aurora 2.80秒，Mysql 2.51秒，Aurora甚至还要低于Mysql。

Aurora优化的是底层架构，而数据库层面，仍然兼容传统的Mysql或PostgreSQL。如果并发量不大，Aurora的优势没有发挥出来，和Mysql的性能表现可能差不多。但是，随着并发量增加，Aurora的性能会超过Mysql。

我们在选择数据库时，通常会进行测试对比。测试时，一定要保证两边的环境一致，包括节点数量，类型，数据库参数等等。如果只是简单跑几个查询，可能出现的情况是，本地物理机上自己搭建的Mysql，比Aurora要快。因为本地是单机，SSD磁盘，不需要经过网络通信。数据库没有压力的时候，处理速度更快。

压力测试一定要并发足够大，大到把CPU利用率打满，并且持续一段时间。没有压力的测试是不准确的。可能的话，尽量可以用接近生产环境的测试数据和语句，更加模拟真实场景的压力。

数据库参数也会对测试结果影响很大。例如，Aurora启用了binlog，并且设置了innodb_flush_log_at_trx_commit=1，也会影响性能。默认Aurora没有启用binlog，只读副本可以访问和主节点一样的底层共享存储，不需要以binlog从主节点同步。Aurora binlog，适用于跨区域同步，或者与其他Mysql进行同步。

Redshift

如果需要对海量数据进行复杂的查询，这是属于OLAP的场景。例如，在10TB的数据中，按照某个产品的消费额，查询出某个时间段的TOP 10用户。普通的OLTP数据库擅长在线交易，如此海量的查询，难以胜任。即使勉强能查询，所花费的时间远超业务能承受的范围。对于海量数据的查询，可以考虑把数据通过ETL工具，抽取到专门的数据仓库，例如Amazon Redshift，来进行查询，性能会有极大提高。Redshift在设计表时，要遵循最佳实践，包括事实表和维度表选择、分配键、排序键、压缩等等。表设计的好坏与否，在性能表现上差别可达几倍甚至几十倍。

以下测试，在Redshift测试同样的表，同样的查询，响应时间是62 ms，大幅低于Aurora和Mysql 的2秒多。

dev=# select count(*) from user_test where create_time between ‘2013-01-01 00:00:00’ and ‘2015-01-01 00:00:00’ and age =31;

count

——-

60633

(1 row)

Time: 62.148 ms

这还只是简单的单表查询，数据量也不大，而且还没有做过优化。Redshift更擅长的是，海量数据里的各种表，做复杂的联合查询。此时表现更加优异。

不过，Redshift并不适合大并发的查询，或者写入。虽然支持SQL insert, update等语句，但是并不建议直接更新表。在插入数据时，需要从S3的CSV等格式化文件批量导入。

在很多业务场景中，例如广告、电商等，Mysql数据库用于OLTP实时在线交易。还有分析系统，需要每隔一段时间从数据库中获取生产数据，导入数据仓库，让分析系统查询处理，得出报表并展现给用户。导入过程使用ETL工具，可以使用Amazon Glue服务，或者使用Talend等第三方工具，或者自己编写spark程序。在此场景中，无论使用何种ETL工具，都要尽量避免实时更新Redshift等数据仓库。Amazon Glue在数据导入Redshift之前，先把数据写入临时的S3，再批量Copy到Redshift。其他工具也应该遵守此实践。

请记住，数据仓库不适合实时更新。

以下架构描述了数据ETL过程。日志和RDS数据库，通过Glue ETL导入到Redshift，查询分析后进行展现。

除了性能方面，还有很多方面需要考虑。数据库和Redshift数据仓库属于不同的场景，这里主要以Aurora和Mysql进行技术对比。

存储

Aurora无需事先指定存储大小和IOPS，根据实际数据量以每10GB自动扩展，存储最大容量可达64TB。这省去了磁盘容量或者IO不足时，需要扩容而带来的影响。

Aurora只支持Innodb存储引擎。如果需要用到MyISAM，那么还是适合使用RDS Mysql。

扩展性

Aurora最多支持15个只读副本，相比Mysql 5个副本有很大提高。Aurora的只读副本有reader endpoint，能够对只读请求做负载均衡。对于应用程序来说，只需指定只读endpoint，就无需再考虑只读副本的流量均衡与故障切换。而Mysql还没有提供只读副本的负载均衡功能，需要在应用程序和数据库之间，加入中间件，或者在应用程序加入逻辑，把请求尽量平均分配给数据库只读副本。否则，一旦Mysql只读副本出现故障，域名或者IP会变化，应用程序端还需要调整。

Aurora还支持Autoscaling自动扩展，根据CPU使用率或连接数，超过指定阈值时，自动增加只读副本，以满足业务变化的需求。

可靠性

Aurora写入时自动复制数据到3个AZ的6个副本，持续把日志和数据备份到更可靠的S3，数据不会丢失。自动故障恢复，能在主节点出现故障时，自动提升只读副本为主节点，实现数据库高可用。

Aurora还有快速恢复等功能，即使在数据库需要恢复时，也能更快启动数据库。

回溯功能更可以在短时间内恢复到之前的某个时间点，而无需重新恢复新的数据库，这需要更改应用程序指向新的数据库。

Aurora和Mysql都支持跨区域副本复制。Aurora还推出了Global Database功能，物理层面进行数据复制，相对与Mysql binlog同步，效率更高，跨区域主从延迟能达到1秒以内。

成本

Aurora和Mysql的费用都包含流量和备份，这些价格相近。不同的地方在于数据库实例和存储费用。

以下是两者在美国东部地区的价格对比：

Aurora R4

RDS Mysql R4 Single-AZ

Aurora Storage and IO

Mysql Provisioned IOPS (SSD) Storage Multi-AZ

实例价格上，Aurora大约是RDS Mysql的1.2倍(9.28/7.68=1.2)。看上去Aurora贵一些。考虑到Aurora相比Mysql的性能优势，同样的业务量场景下，即使Aurora相对Mysql只提升了2倍的性能，成本也会降低很多。例如，Mysql需要4个r4.xlarge节点，Aurora由于性能提升，只需要2个r4.xlarge即可满足业务需求，总成本上，Aurora 0.58*2=1.16，Mysql 0.48*4=1.92，Aurora更便宜。

存储价格上，容量价格Aurora便宜一些(0.1 vs 0.125)，而且Aurora按实际容量收费，对比RDS在创建实例时就要指定存储容量，价格会更便宜。Aurora 实际容量，可以在Cloudwatch监控的[Billed] Volume Bytes Used 指标查看。

IO价格不好直接比较，Mysql Provision IOPS EBS (IO1) 按照预设容量收费，此费用固定。Aurora按照IO总量计算，不同时段的IO请求不一样，费用也不同。可以监控Cloudwatch [Billed] Volume Read IOPS 和 [Billed] Volume Write IOPS 这两个读写IO的指标，估算某个请求量的场景下，所花费的IO。如果开启了Aurora并行查询，IO费用会更高。

以下总结了Aurora/Mysql/Redshift的应用场景、特性和成本对比。

本篇作者