尝试使用 Aurora，没有发现它的查询速度很快
Experimenting with Aurora, not seeing that it is fast with queries
我正在为我的 MySQL 数据库试用 Amazon Aurora。当我 运行 mysqldump 时，我的数据库大约有 600 GB。我在本地有一个 运行ning 实例，一个在我的 VPS 中，一个带有 Aurora（我在过去 24 小时内上传）。
当我在这三个环境中的每一个上 运行 "select sql_no_cache * from employees;" 时，我发现 Aurora 需要更长的时间才能 return 超过 100 万条记录。我正在尽我所能将苹果与苹果进行比较。我有 运行 这个查询 MySQL Workbench 和一个终端。结果在本地大约3.5s，在Aurora上VPS到214s。
在我放弃 Aurora 之前，知道为什么我会看到性能是标准性能 5 倍的技术所无法预料的性能 MySQL 吗？像查询 MySQL 数据库（使用 Workbench 或终端）那样查询我的 Aurora 数据库是不切实际的性能测试吗？我需要做一些进一步的配置或调整吗？
我相信极光很快，所以我一定是做错了什么。如果从我这端查询这么慢，那么我希望如果我的应用程序查询它，它会是相似的。
是的，测量从连接到 RDS Aurora 实例的本地工作站上的 Workbench/Terminal 客户端返回 100 万条记录的单个 select sql_no_cache * from employees; 查询的响应时间是一项不切实际的性能测试。这不仅不是同类比较，而且您的应用在生产环境中查询数据库时也不会（或不应）表现出相似的行为。
首先，比较苹果与苹果：
- 运行 您在具有相同计算能力（CPU speed/count、RAM、磁盘 I/O）的服务器上进行的测试。如果您的本地工作站 VPS 和 RDS 实例不同，这将影响您的比较。将 RDS 实例 运行ning Aurora 与实例类型完全相同（例如
r3.8xlarge）的 RDS 实例 运行ning MySQL 进行比较。
- 跨越相同的网络边界建立测试 client/server 连接。与从本地实例 运行ning 通过本地套接字发送数据相比，通过笔记本电脑的 Internet 连接发送一百万行数据可能需要很长时间。确保您的测试服务器位于同一个通用网络（例如，它们都在 AWS 中的同一个 region/availability 区域），以确保网络连接具有一致的属性。
- 使用相同的查询和相同的源数据（听起来您已经在这样做了）。
其次，运行 测试类似于您的应用查询数据库时所期望的测试：
- 测量并发查询吞吐量（每秒请求数），而不是单个查询性能（每个请求秒数）。对于关系数据库，您的数据库可以处理的并发事务数（这限制了您的应用程序可以处理的用户数）可能与独立完成单个查询所花费的时间一样重要（或更多）。
sysbench 是一个标准的数据库基准测试工具，可以启动一系列并发查询和测量 requests/sec。
- 运行 大量小查询，而不是单个大查询。尽管您的应用程序可能不同，但 Web 应用程序往往会为大量并发用户提取少量个性化数据（想想一个网页显示有关单个对象的详细信息，而不是单个页面上的一百万个对象）。
sysbench 中的 OLTP（在线事务处理）基准测试提供了类似于典型 Web 应用程序工作负载的 set of queries。 Long-运行ning、full-table-scan 类型的查询在 Amazon Redshift 等数据仓库产品上得到了更好的优化。
- 从与数据库位于同一网络中的另一台计算机建立您的 client/server 连接。您的 Web 服务器应部署在物理上尽可能靠近数据库的位置，以便网络带宽高且延迟低。否则，网络连接可能是比其他任何事情都更大的瓶颈。
- 使用大型多 CPU 实例进行测试。 Aurora 的许多优化都侧重于跨多个 CPU 核心线性扩展读+写吞吐量。对于一个很小的单个 CPU 实例，您可能不会看到比 MySQL 有多少吞吐量改进。
r3.8xlarge 实例类型有 32 CPUs，并且在 Aurora 的优化下性能会更好。
要重现 Amazon 使用的准确性能基准，您可以遵循 Amazon Aurora Performance Benchmarking Guide 中的详细设置细节。
有关 5 倍性能声明背后的具体数字，请参阅 Verbitski 等人。 (2017), "Amazon Aurora: High Design Considerations
吞吐量云原生关系数据库：
Aurora’s performance doubles for each higher instance size and for the r3.8xlarge achieves 121,000 writes/sec and 600,000 reads/sec which is 5x that of MySQL 5.7 which tops out at 20,000 [writes]/sec and 125,000 [reads]/sec.
我正在为我的 MySQL 数据库试用 Amazon Aurora。当我 运行 mysqldump 时，我的数据库大约有 600 GB。我在本地有一个 运行ning 实例，一个在我的 VPS 中，一个带有 Aurora（我在过去 24 小时内上传）。
当我在这三个环境中的每一个上 运行 "select sql_no_cache * from employees;" 时，我发现 Aurora 需要更长的时间才能 return 超过 100 万条记录。我正在尽我所能将苹果与苹果进行比较。我有 运行 这个查询 MySQL Workbench 和一个终端。结果在本地大约3.5s，在Aurora上VPS到214s。
在我放弃 Aurora 之前，知道为什么我会看到性能是标准性能 5 倍的技术所无法预料的性能 MySQL 吗？像查询 MySQL 数据库（使用 Workbench 或终端）那样查询我的 Aurora 数据库是不切实际的性能测试吗？我需要做一些进一步的配置或调整吗？
我相信极光很快，所以我一定是做错了什么。如果从我这端查询这么慢，那么我希望如果我的应用程序查询它，它会是相似的。
是的，测量从连接到 RDS Aurora 实例的本地工作站上的 Workbench/Terminal 客户端返回 100 万条记录的单个 select sql_no_cache * from employees; 查询的响应时间是一项不切实际的性能测试。这不仅不是同类比较，而且您的应用在生产环境中查询数据库时也不会（或不应）表现出相似的行为。
首先，比较苹果与苹果：
- 运行 您在具有相同计算能力（CPU speed/count、RAM、磁盘 I/O）的服务器上进行的测试。如果您的本地工作站 VPS 和 RDS 实例不同，这将影响您的比较。将 RDS 实例 运行ning Aurora 与实例类型完全相同（例如
r3.8xlarge）的 RDS 实例 运行ning MySQL 进行比较。 - 跨越相同的网络边界建立测试 client/server 连接。与从本地实例 运行ning 通过本地套接字发送数据相比，通过笔记本电脑的 Internet 连接发送一百万行数据可能需要很长时间。确保您的测试服务器位于同一个通用网络（例如，它们都在 AWS 中的同一个 region/availability 区域），以确保网络连接具有一致的属性。
- 使用相同的查询和相同的源数据（听起来您已经在这样做了）。
其次，运行 测试类似于您的应用查询数据库时所期望的测试：
- 测量并发查询吞吐量（每秒请求数），而不是单个查询性能（每个请求秒数）。对于关系数据库，您的数据库可以处理的并发事务数（这限制了您的应用程序可以处理的用户数）可能与独立完成单个查询所花费的时间一样重要（或更多）。
sysbench是一个标准的数据库基准测试工具，可以启动一系列并发查询和测量 requests/sec。 - 运行 大量小查询，而不是单个大查询。尽管您的应用程序可能不同，但 Web 应用程序往往会为大量并发用户提取少量个性化数据（想想一个网页显示有关单个对象的详细信息，而不是单个页面上的一百万个对象）。
sysbench中的 OLTP（在线事务处理）基准测试提供了类似于典型 Web 应用程序工作负载的 set of queries。 Long-运行ning、full-table-scan 类型的查询在 Amazon Redshift 等数据仓库产品上得到了更好的优化。 - 从与数据库位于同一网络中的另一台计算机建立您的 client/server 连接。您的 Web 服务器应部署在物理上尽可能靠近数据库的位置，以便网络带宽高且延迟低。否则，网络连接可能是比其他任何事情都更大的瓶颈。
- 使用大型多 CPU 实例进行测试。 Aurora 的许多优化都侧重于跨多个 CPU 核心线性扩展读+写吞吐量。对于一个很小的单个 CPU 实例，您可能不会看到比 MySQL 有多少吞吐量改进。
r3.8xlarge实例类型有 32 CPUs，并且在 Aurora 的优化下性能会更好。
要重现 Amazon 使用的准确性能基准，您可以遵循 Amazon Aurora Performance Benchmarking Guide 中的详细设置细节。
有关 5 倍性能声明背后的具体数字，请参阅 Verbitski 等人。 (2017), "Amazon Aurora: High Design Considerations 吞吐量云原生关系数据库：
Aurora’s performance doubles for each higher instance size and for the r3.8xlarge achieves 121,000 writes/sec and 600,000 reads/sec which is 5x that of MySQL 5.7 which tops out at 20,000 [writes]/sec and 125,000 [reads]/sec.