Jul
28
上篇对比了阿里云、腾讯云、UCloud的云数据库,没想到文章被 Linux.cn 推荐,并被今日头条收录,影响范围颇大,相关云数据库团队都有工程师跟我取得了联系,尤其是阿里云和腾讯云的同学表示内部自测的性能并不差,向我要了具体的测试参数做核对;此外Linux中国的微信号下也有好奇宝宝回复表示想知道具体的测试命令和参数等。因此抽了点时间写个续篇,补充一些上篇没有提到的内容。
腾讯云的同学在测试完以后反馈,TPS 达到了 750 左右,与上篇中的结果相差悬殊。收到邮件,我感到深深的忧虑,难道之前的测试有问题?由于阿里云的同学说有些客户反馈性能差是因为测试的主机离数据库比较远,于是我重新申请了和上次配置一致的云数据库和云主机(并且特意check了所在分区是否一致),再次执行测试,发现在腾讯云上达到了 733 TPS,确实远超之前的测试结果。稳妥起见,我在阿里云和UCloud也申请了新的主机和数据库,再跑了一遍测试,结果如下:
两次的结果并不是很稳定(证明了上次的测试确实有点粗糙,至少应该测几次取均值),然而在腾讯云上测试的两次结果相差过于悬殊,远不是误差能够解释的。所以我仔细研究了一下各家云数据库的说明,发现了一点玄机:
如上图所示,针对测试选择的实例,腾讯云和阿里云明确说明了实例的标称QPS,而UCloud则没有明确说明。从使用方的角度,我认为这个标称值是实例能保证的QPS,测试结果也间接证明了这一点。
可以看出,因为使用的是标准化测试工具,TPS和QPS是之间有着1:27的比例关系。参考腾讯云标称的 7200 QPS,那么第一次测试的 7500 QPS / 277.8 TPS 就可以解释得通了:可能是该实例所在的物理机上负载较高所以执行了严格的限制,也可能是腾讯云不同机器上部署的频控策略不同(AB测试?),总之不巧正好测到了限制比较严格的实例。
从表中还可以看出一些其他比较有意思的地方:
1. 阿里云之所以表现得垫底,是因为QPS限制在4000,虽然第一次测试达到了5700,但仍然低于另外两家。如果能够采用最高档次的实例(14000 QPS),那么至少也能达到 500+ TPS,并不差。
2. 实测QPS最高的是UCloud,远高于另外两家同档次的实例;他们在文档中给出了一组测试结果,号称最高能达到5.8万QPS。但是UCloud给自己留了余地,没有标称值,没有做出承诺,显得不够严谨。此外,我觉得,不能基于低QPS就武断地认为技术实力弱(想想双十一的量,阿里都扛得住),可能只是具体的运营或开发策略不同。
两次测试和进一步的分析更完整地体现了三家云数据库的状况。但正如上篇所说,性能往往并不是唯一/最高标准:即使选择了限制最严格的阿里云,在千万级的数据量下仍然能达到 200+ TPS,已经远超大部分业务的实际需求了。
具体的测试脚本我放到了 Gist 上,供参考,如有不妥之处,欢迎指教探讨:
转载请注明出自 ,如是转载文则注明原出处,谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。
复测
腾讯云的同学在测试完以后反馈,TPS 达到了 750 左右,与上篇中的结果相差悬殊。收到邮件,我感到深深的忧虑,难道之前的测试有问题?由于阿里云的同学说有些客户反馈性能差是因为测试的主机离数据库比较远,于是我重新申请了和上次配置一致的云数据库和云主机(并且特意check了所在分区是否一致),再次执行测试,发现在腾讯云上达到了 733 TPS,确实远超之前的测试结果。稳妥起见,我在阿里云和UCloud也申请了新的主机和数据库,再跑了一遍测试,结果如下:
分析
两次的结果并不是很稳定(证明了上次的测试确实有点粗糙,至少应该测几次取均值),然而在腾讯云上测试的两次结果相差过于悬殊,远不是误差能够解释的。所以我仔细研究了一下各家云数据库的说明,发现了一点玄机:
如上图所示,针对测试选择的实例,腾讯云和阿里云明确说明了实例的标称QPS,而UCloud则没有明确说明。从使用方的角度,我认为这个标称值是实例能保证的QPS,测试结果也间接证明了这一点。
可以看出,因为使用的是标准化测试工具,TPS和QPS是之间有着1:27的比例关系。参考腾讯云标称的 7200 QPS,那么第一次测试的 7500 QPS / 277.8 TPS 就可以解释得通了:可能是该实例所在的物理机上负载较高所以执行了严格的限制,也可能是腾讯云不同机器上部署的频控策略不同(AB测试?),总之不巧正好测到了限制比较严格的实例。
从表中还可以看出一些其他比较有意思的地方:
1. 阿里云之所以表现得垫底,是因为QPS限制在4000,虽然第一次测试达到了5700,但仍然低于另外两家。如果能够采用最高档次的实例(14000 QPS),那么至少也能达到 500+ TPS,并不差。
2. 实测QPS最高的是UCloud,远高于另外两家同档次的实例;他们在文档中给出了一组测试结果,号称最高能达到5.8万QPS。但是UCloud给自己留了余地,没有标称值,没有做出承诺,显得不够严谨。此外,我觉得,不能基于低QPS就武断地认为技术实力弱(想想双十一的量,阿里都扛得住),可能只是具体的运营或开发策略不同。
总结
两次测试和进一步的分析更完整地体现了三家云数据库的状况。但正如上篇所说,性能往往并不是唯一/最高标准:即使选择了限制最严格的阿里云,在千万级的数据量下仍然能达到 200+ TPS,已经远超大部分业务的实际需求了。
彩蛋
具体的测试脚本我放到了 Gist 上,供参考,如有不妥之处,欢迎指教探讨:
#!/bin/bash
#注:很多发行版自带SysBench的是0.4.12,但有些参数(如oltp-tables-count)是0.5才支持的,建议从官方源获取源码编译运行
#注2:ubuntu 16.04 上面编译如果报错说没有 libmysqlclient_r.so ,自己建一个软链接就好了
#注3:需要先create database mysql, 并对用于测试的用户授予 sbtest 这个库的读写权限。
cmd="sysbench --test=/root/src/sysbench-0.5/sysbench/tests/db/oltp.lua \
--oltp-table-size=2000000 \
--oltp-tables-count=20 \
--oltp-range-size=100 \
--oltp-point-selects=10 \
--oltp-simple-ranges=6 \
--oltp-sum-ranges=2 \
--oltp-order-ranges=3 \
--oltp-distinct-ranges=2 \
--oltp-index-updates=1 \
--oltp-non-index-updates=1 \
--num-threads=32
--max-requests=0
--max-time=1800
--report-interval=10
--rand-init=on
--rand-type=special
--rand-spec-iter=12
--rand-spec-pct=10
--rand-spec-res=75
--verbosity=3
--mysql-host=10.0.0.1
--mysql-port=3306
--mysql-user=root
--mysql-password=123456
"
$cmd cleanup
$cmd prepare
$cmd run
#注:很多发行版自带SysBench的是0.4.12,但有些参数(如oltp-tables-count)是0.5才支持的,建议从官方源获取源码编译运行
#注2:ubuntu 16.04 上面编译如果报错说没有 libmysqlclient_r.so ,自己建一个软链接就好了
#注3:需要先create database mysql, 并对用于测试的用户授予 sbtest 这个库的读写权限。
cmd="sysbench --test=/root/src/sysbench-0.5/sysbench/tests/db/oltp.lua \
--oltp-table-size=2000000 \
--oltp-tables-count=20 \
--oltp-range-size=100 \
--oltp-point-selects=10 \
--oltp-simple-ranges=6 \
--oltp-sum-ranges=2 \
--oltp-order-ranges=3 \
--oltp-distinct-ranges=2 \
--oltp-index-updates=1 \
--oltp-non-index-updates=1 \
--num-threads=32
--max-requests=0
--max-time=1800
--report-interval=10
--rand-init=on
--rand-type=special
--rand-spec-iter=12
--rand-spec-pct=10
--rand-spec-res=75
--verbosity=3
--mysql-host=10.0.0.1
--mysql-port=3306
--mysql-user=root
--mysql-password=123456
"
$cmd cleanup
$cmd prepare
$cmd run
欢迎扫码关注:
转载请注明出自 ,如是转载文则注明原出处,谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。