【IT168 评论】谷歌云端数据库在线程较少的情况下，性能上还是可能击败亚马逊的Aurora，但Aurora目前仍处于第一的位置。谷歌云SQL第二代严格上来说仍然是测试版，但它声称性能比公司的第一代基于SQL的云数据库高七倍，功能强20%。双11在即，数据库的能力不容小觑，那我们就来看看谷歌云SQL与亚马逊Aurora的性能对比，到底孰优孰劣?
许多web应用都建在开源堆栈的基础上，包括MySQL。尽管有其局限性，MySQL还是想方设法成为世界上使用最广泛的开源RDBMS。但MySQL处理范围确实有限，特别是与商业数据库相比，不能很好地处理大量并发用户请求。
亚马逊Aurora和谷歌云端数据库起初的开发宗旨都是为了给用户提供高性能、高可伸缩性的MySQL数据库服务。每个效果不错的应用程序都不仅仅停留在同一个云提供商，而是存在一个可用性区域，最小化服务之间的延迟，最大化堆栈内的网络吞吐量。本文将给出不同的客户端线程事务负载时，亚马逊Aurora和谷歌云端数据库的表现。
云端SQL性能基准测试
基准测试很难正确执行，这种方式看起来好像毫无意义，但听起来却让人印象深刻。
对于亚马逊Aurora，我或多或少参考了亚马逊的基准，尽管有些难度。我起初记录了亚马逊只读和只写Sysbench测试的部分数据。在对比了我自己的与亚马逊的引擎配置之后，我改变了客户的可用性区域去匹配数据库的可用性区域，实际上记录的写数据要高于亚马逊给出的。事实证明，Aurora的写效率往往一开始比较高，然后趋于平稳，我运行的测试程序比亚马逊给出的要稍短一点。本来有几个小的配置细节我比较担心，但实际上是没有问题的，亚马逊主要是在Linux网络路由设置中对网络驱动程序进行了加强。
第一次看到谷歌云端数据库时，我感觉我没有足够的时间和资源复制谷歌云端数据库的事务Sysbench测试。我试图复制也尝试了不同的配置，但还是进行缓慢。但对用户而言，选取谷歌云端数据库和亚马逊Aurora可能更具代表性。在这个过程中，我也得到了谷歌和亚马逊工程师的支持，以确保测试的数据库是合适的。
接下来，你可以看到一些试用结论和心得：
上图为并发Sysbench线程每个线程的磁盘绑定事务率。测试对象为两个谷歌云端数据库第二代实例(db-n1-highmem-16)，两个亚马逊Aurora实例，亚马逊Aurora 4xlarge和8xlarge。
我使用了Sysbench进行在线事务分析处理，它是一款MySQL社区内非常受欢迎的基准测试工具，并且用不同的客户端线程数代表不同数量的客户。在两个实例中，我们都创建了单故障转移副本。但要注意，如果你使用的是亚马逊Aurora的集群端点，主数据库扮演写角色，从数据库扮演读角色。
我进行了几次尝试并且得到了谷歌和亚马逊工程师的帮助，我的第一次尝试最终以256个线程结束。加载数据库花费了五个小时，运行OLTP测试每个线程花费了半小时。从上图中看，低于16个线程以下的每个线程的磁盘绑定率，谷歌云数据库第二版要优于亚马逊。而在16个线程之后，亚马逊的两个版本要更优，尤其是亚马逊Aurora 8xlarge。
我对亚马逊Aurora的测量其实要高于他们给出的线程计数。这使我不得不怀疑谷歌工程师的基准测试可能有所落后了，或许因为亚马逊增强了网络驱动。谷歌发布的Ubuntu Trusty脚本和附带该脚本的MySQL客户端版本，初次运行，我必须修改谷歌云运行Ubuntu Xenial安装脚本的部分配置，然后再运行亚马逊云的Red Hat。
出于完整性的考虑,让我们也看看实际的事务率:
以及测量延迟:
事务率似乎和单个线程的事务率诉说着同样的故事。从图表来看，谷歌的延迟十分严重，尤其是随着线程数的不断增加，延迟越来越大。要注意的是，即便客户端的线程数已经很高了，但亚马逊Aurora 8xlarge仍然有20%的CPU空闲。
如果你希望数据库更快，你可能希望得到适合内存的最大的数据库表大小。在上面的测试中，使用的表大约有2000万行，远远超过了测试对象的承受能力，接下来将使用400万行的表，以适应所测试的所有数据库。
大体的特点是，事务率高的延迟低。反映出的事实是大部分读操作被缓存在内存中，尽管写必须被放在固态磁盘上进行。
如果你正在计划扩大你的表大小以最大限度地适应内存，那这些图表分析可能是你想看到的。如果你想要的数据库延迟小于500ms，你所得到的线程数大概在256个左右。而这之中，亚马逊Aurora 8xlarge可能达到512个线程，并且延迟极低。
总结
正如我们所看到的，亚马逊不单单是起步早，它在性能上的表现比谷歌要优秀很多，但是当线程数很少的时候，谷歌也是一个不错的选择。严格地说，谷歌云SQL第二代还处于测试版，不知道经过此番较量，谷歌会不会推迟正式版的发行呢。
