发布于: Nov 30, 2022
【概要】云数据库优化包含针对大型表以及大量表的优化，以及在资源利用率的提高，本文将着重介绍两种优化过程及影响。
云数据库优化包含针对大型表以及大量表的优化，以及在资源利用率的提高，本文将着重介绍两种优化过程及影响。
整合工作负载还可能导致 Aurora 集群中存储大量的表。实际上，可以合理地整合到单个 Aurora 集群上的表的数量取决于您的工作负载和访问模式。
MySQL 社区版本的文件系统特性会限制数据库的可扩展性（就表的大小和数量而言），与之不同，Aurora MySQL 使用专用的分布式日志结构化存储服务。因此，在 MySQL 中使用自定义表空间配置来缓解文件系统的继承限制的许多原因不适用于 Aurora。从操作上或从故障恢复的角度来看，拥有大量的表没有与文件系统相关的影响。虽然您可以使用 Aurora 自定义数据库集群参数组关闭 inndb_file_per_table 选项，但我们不建议这样做，因为它不再影响性能或恢复时间。
但是，Aurora 中的大量的表确实会影响内存利用率。具有默认参数的 Aurora 集群的内存消耗如下。
| 数据库实例使用的内存 | 消耗者 |
| 3/4 | 缓冲池（页面缓存），用于存储最近访问的数据页面。您可以在数据库参数组中更改此配置。但是，通常最好要减小缓冲池的大小。用于跟踪缓冲池有效性的相关 Amazon CloudWatch 指标有缓冲池缓存命中率和对存储的读取 IOPS。 |
| 1/24 | 查询缓存。MySQL 社区版本从版本 5.7.20 开始，不推荐使用并禁用查询缓存，与之不同，Aurora 拥有经过重新设计的查询缓存。此查询缓存不受社区版本中实现的限制。我们建议您启用查询缓存，除非您确信查询不可缓存，并且希望回收内存以用于其他缓冲区和缓存。 |
| 剩余部分 | 剩余可用内存（约 20.8％）由各种其他不太可预测的消耗者使用，例如全局或特定于连接或会话以及操作系统和托管服务进程的数据库引擎缓冲区和缓存。其中一些内存可能可用或可以变得可用。 |
使用大量的表时优化与表相关的缓存
有两个缓存与具有大量的表的工作负载尤其相关。它们的错误配置可能会导致性能和稳定性问题。
表缓存（或表打开缓存）存储由于用户活动导致的表打开的处理程序结构。每个会话都会单独打开一个表，因此如果有多个并发会话访问它，则缓存会包含同一个表的多个副本。在 r4 类 Aurora 数据库实例中，我们已将此缓存的默认大小增加到了最多 6,000 个打开表。但这是一个软限制。根据 SQL 语句中涉及的表（以及这些表中的分区）的数量，此缓存可能成为主要的内存消耗者。您的工作负载在数据库上运行的并发会话数会放大此影响。
表定义高速缓存存储内存中常用表的表定义（架构、元数据）。活动表越多，缓存其定义效果就越好。在 r4 类 Aurora 数据库实例中，我们已将该缓存的默认大小增加到了 20,000 个定义。因此，此缓存可能成为主要的内存消耗者。对于使用数十万个表的工作负载，如果大多数的表处于活跃状态，则可能需要将此缓存的大小增加到超出默认值。此缓存大小也是一个软限制。MySQL 数据库引擎不会移出父子外键相关表的表定义。所以缓存的总大小可能超过缓存大小限制。
因此，高效的内存利用率实际上会限制可以在具有给定大小的实例的 Aurora 集群上运行的表的数量。为了减少这些缓存占用的空间，您可能需要使用更大的数据库实例类来适应它们。或者，您可能需要减少分配给查询缓存或缓冲池的内存量以进行补偿。这种减少反过来可能会以其他方式影响工作负载性能，因为存放在内存中的工作数据集变少。至于多少表算是“太多”很难界定。 以下示例更好地说明了其中一些影响。
下图显示了通过 sysbench 读取和写入 OLTP 测试的增强监测指标报告的可用内存，该测试包含 1,000 个表，仅使用 40 个并发连接。这个工作负载在兼容 MySQL 5.6 的 Aurora db.r4.2xlarge 数据库实例（内存为 61 GB，是一种受欢迎的实例类）上只运行了 10 分钟。
对于此测试，以下命令在测试运行之前准备数据库和表：
sysbench oltp_read_write --table-size=1000 --tables=1000 --threads=40 --time=600 --max-requests=0 --db-driver=mysql --mysql-host=<aurora_db_cluster_endpoint> --mysql-db=sbtest --mysql-user=<user> --mysql-password=<password> prepare
当测试开始时，系统的可用内存突然从超过 12.2 GB 减少 5 GB，并且在整个测试过程中 CPU 资源几乎完全耗尽。与 MySQL 社区版本不同，Aurora 预先分配了缓冲池，并且在之前的测试中它已经预热。我们使用相对较少数量的活动表 (1,000) 和总并发连接 (40) 执行测试。内存消耗主要是由于表缓存和在涉及大量的活动表时每个连接的放大效应。
数据库实例参数组中的 table_open_cache 参数控制表缓存的大小。默认情况下，使用以下公式设置此参数：
lesser of (<数据库实例类内存字节数>/1,179,121) or 6,000
为了便于比较，下面的图表代表了类似的测试。唯一的区别是测试只访问了 500 个表。这里，当测试开始时，系统的可用内存也会从超过 12.2 GB 突然下降约 2.5 GB。
以下示例说明了使用大量表时表定义缓存的影响。此测试中的示例工作负载创建 100,000 个简单表，每个表都具有自动递增的整数主键、时间戳列、浮点列和两个短字符串列。测试使用单个连接在每个简单表中插入一行，在具有 15.25 GB 内存的兼容 MySQL 5.7 的 Aurora db.r4.large 数据库实例上运行。Aurora 集群上没有其他活动正在运行，并且集群开始为空。
您可以看到可用内存随工作负载的增加而下降的情况。可用内存在达到缓存限制时稳定，总共消耗大约 700 MB 的内存，主要用于表定义缓存。
数据库实例参数组中的 table_definition_cache 参数控制表定义缓存的大小。默认情况下，使用以下公式设置此参数：
lesser of (<数据库实例类内存字节数>/393,040) or 20,000
总之，实际可以整合的表的数量取决于几个因素。这些因素包括活动表的数量、可用内存大小以及需要支持的并发连接数。
在本文的前面部分，我们讨论了大型的表或数量巨大的表对某些服务器资源（如 CPU 或内存）利用率的影响。但工作负载整合本身会导致利用率上升。如果减少了数据库分片数，则为每个剩余的数据库分片建立的并发连接可能会更多。每个整合数据库进行更多工作，读写查询量增加。
Amazon Aurora for MySQL 具有内部服务器连接池和线程多路复用，有助于在处理数千个并发连接时减少争用并提高可扩展性。您可以配置每个 Aurora 数据库实例以允许最多 16,000 个并发连接。但是，您的工作负载和数据库实例类选择所能实现的实际最大值可能会低于此值。
每个连接、会话和线程根据当前运行的特定 SQL 语句为各种缓冲区、缓存和其他内存结构消耗可变数量的内存。这种消耗是不确定的，并且与本文前面讨论的其他结构竞争相同数量的可用内存。要了解有效连接管理和扩展的最佳实践，Amazon Aurora MySQL DBA 连接管理手册是一个很好的资源。它包含有用的建议，可帮助您优化更大、更高吞吐量工作负载的连接利用率。
当您将兼容 MySQL 的 Amazon Aurora 作为整合多个数据库工作负载的解决方案时，需要考虑许多因素。我们在帮助客户实施此类整合的过程中，总结出了前面讨论到的一组常见的注意事项，尽管仍不够详尽。每个工作负载都不同，因此整合的实际限制在每种情况下都不同。