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/

只读负载

----	400并发	1000并发	2000并发	3000并发	4000并发	5000并发	6000并发
QPS mysql	112K	108K	95K	88K	44K	17K	8.9K
QPS aurora	440K	680K	776K	748K	726K	683K	659K
CPU mysql	98	99	99	99	90	57	39
CPU aurora	90	96	97	98	98	98	98
Response time mysql	39.27ms	103.08ms	230.70ms	365.23ms	974.83ms	4106.50ms	8076.35ms
Response time aurora	11.71ms	19.12ms	33.10ms	51.32ms	72.03ms	93.36ms	114.96ms

读/写混合负载

----	400并发	1000并发	2000并发	3000并发	4000并发	5000并发	6000并发
QPS mysql	84K	88K	76K	56K	29K	28K	16K
QPS aurora	160K	188K	184K	172K	152K	140K	128K
CPU mysql	75	81	90	69	73	81	87
CPU aurora	77	92	97	97	98	98	98
Response time mysql	68.94ms	168.17ms	384.80ms	778.60ms	2073.83ms	2569.24ms	5815.39ms
Response time aurora	38.89ms	81.51ms	163.37ms	259.77ms	391.70ms	534.18ms	638.33ms

可以明显看到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

db.r4.large	$0.29
db.r4.xlarge	$0.58
db.r4.2xlarge	$1.16
db.r4.4xlarge	$2.32
db.r4.8xlarge	$4.64
db.r4.16xlarge	$9.28

RDS Mysql R4 Single-AZ

db.r4.large	$0.24
db.r4.xlarge	$0.48
db.r4.2xlarge	$0.96
db.r4.4xlarge	$1.92
db.r4.8xlarge	$3.84
db.r4.16xlarge	$7.68

Aurora Storage and IO

Storage Rate	$0.10 per GB-month
I/O Rate	$0.20 per 1 million requests

Mysql Provisioned IOPS (SSD) Storage Multi-AZ

Storage Rate	$0.125 per GB-month
Provisioned IOPS Rate	$0.10 per IOPS-month

实例价格上，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.582=1.16，Mysql 0.484=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的应用场景、特性和成本对比。

----	Aurora	Mysql	Redshift
应用场景	高并发OLTP	普通OLTP	OLAP海量数据仓库复杂分析查询
性能	数倍于Mysql，大量只读请求优势更加巨大	高并发时性能下降明显	少量但是复杂的查询，不适合实时写入
存储	存储计算分离，按使用量计费	指定EBS存储容量和IO	指定节点类型和数量，不能只扩容存储
扩展性	最多15个只读副本，多个副本负载均衡，支持Autoscaling	最多5个只读副本，需要单独实现副本负载均衡	最多128个节点
可靠性	3 AZ/ 6副本，自动故障切换，快速恢复，回溯，跨区域复制	自动故障切换，跨区域复制	数据在每个节点都有多个副本
成本	同样业务所需节点数量或类型更小，总成本较低	节点单价略低，但是总成本相对Aurora更高	相对较高

作者介绍：

章平
亚马逊 AWS 解决方案架构师。2014年加入 AWS 技术支持团队，解决客户疑难杂症，熟悉各种用户场景。对于各类云计算产品和技术，特别是在数据库和大数据方面，拥有丰富的技术实践和行业解决方案经验。

本文转载自AWS技术博客

文章链接：
https://amazonaws-china.com/cn/blogs/china/aurora-mysql-redshift-application-scene-cost-analysis/

创作场景

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