发布于: Jul 22, 2022
Aurora/Mysql/Redshift 这三款产品如何选择，来满足自己的业务需求呢？接下来我们会从技术和成本方面详细分析。
说到云数据库的优点，就不得不提到 Amazon Aurora。Amazon Aurora 作为 Amazon Web Services 增长最快的服务，已经在中国宁夏区域可用。越来越多的客户选择 Aurora 作为核心关系型数据库，处理核心数据业务。除了 Aurora 之外， Amazon Web Services 还提供了 RDS Mysql 等数据库引擎供客户选择。另外，Amazon Web Services 还有 Amazon Redshift 数据仓库产品，作为海量大数据分析使用。
那么，如何选择合适的产品，来满足自己的业务需求呢？接下来我们会从技术和成本方面，详细分析 Aurora/Mysql/Redshift 这三款产品。
Aurora 日志即数据库+计算存储分离的设计理念，使得 Aurora 拥有相比传统数据库更高的性能表现。
以下是 Amazon Web Services 数据库专家使用 Sysbench 工具对 Aurora 和 Mysql 5.6 分别进行压力测试的结果。实例类型 r4.8xlarge (32 vCPU, 244GB 内存)。
可以明显看到 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 加入了并行查询的支持，利用底层存储节点的计算能力，进行并行计算，大幅提升查询速度。
Aurora 的优势，在大并发的场景下表现得淋漓尽致。那么，是否所有场景都适合 Aurora 呢？
在频繁更新的业务场景下，如果 Innodb 表添加了二级索引，并且禁用了 changebuffer，那么由于没有索引写缓存，直接写入磁盘会极大影响性能。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 进行同步。
如果需要对海量数据进行复杂的查询，这是属于 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 进行技术对比。