Feb 1

墙外最老牌云数据库测试 不指定

felix021 @ 2018-2-1 00:03 [IT » ] 评论(0) , 引用(0) , 阅读(215) | Via 本站原创
平台:AWS Aurora (MySQL 5.6.10a 兼容版本)

测试软件:sysbench 0.5 --test=oltp.lua (与之前一样的测试脚本

DB配置:db.r4.large (2核,约16GB RAM),Aurora Shared Disk

sysbench配置:m4.xlarge(4核,16GB RAM),20GB+100GB EBS(300/3000 IOPS)

测试结果:

tps: 276 tps
reads: 6400 tps
writes: 1100 tps
response time: 130ms (95%)

测试结果:
引用

[  10s] threads: 32, tps: 174.89, reads: 4077.58, writes: 705.68, response time: 305.44ms (95%), errors: 0.00, reconnects:  0.00
[  20s] threads: 32, tps: 230.00, reads: 5302.10, writes: 916.00, response time: 236.40ms (95%), errors: 0.00, reconnects:  0.00
[  30s] threads: 32, tps: 248.90, reads: 5680.20, writes: 994.70, response time: 219.35ms (95%), errors: 0.00, reconnects:  0.00
[  40s] threads: 32, tps: 250.10, reads: 5776.60, writes: 1000.00, response time: 219.16ms (95%), errors: 0.00, reconnects:  0.00
[  50s] threads: 32, tps: 253.20, reads: 5811.50, writes: 1012.00, response time: 205.62ms (95%), errors: 0.00, reconnects:  0.00
[  60s] threads: 32, tps: 252.30, reads: 5832.70, writes: 1009.60, response time: 197.89ms (95%), errors: 0.00, reconnects:  0.00
...
...
[1780s] threads: 32, tps: 279.00, reads: 6403.60, writes: 1115.30, response time: 135.88ms (95%), errors: 0.00, reconnects:  0.00
[1790s] threads: 32, tps: 276.30, reads: 6391.30, writes: 1106.80, response time: 155.70ms (95%), errors: 0.00, reconnects:  0.00
[1800s] threads: 32, tps: 276.90, reads: 6343.60, writes: 1106.80, response time: 131.83ms (95%), errors: 0.00, reconnects:  0.00
OLTP test statistics:
    queries performed:
        read:                            11371476
        write:                          1977648
        other:                          988824
        total:                          14337948
    transactions:                        494412 (274.66 per sec.)
    read/write requests:                13349124 (7415.78 per sec.)
    other operations:                    988824 (549.32 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          1800.0982s
    total number of events:              494412
    total time taken by event execution: 57593.8148s
    response time:
        min:                                24.28ms
        avg:                                116.49ms
        max:                                505.90ms
        approx.  95 percentile:            142.84ms

Threads fairness:
    events (avg/stddev):          15450.3750/15.24
    execution time (avg/stddev):  1799.8067/0.02
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 上,供参考,如有不妥之处,欢迎指教探讨:

#!/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
Jul 11

墙内三大云数据库测试对比 不指定

felix021 @ 2016-7-11 22:26 [IT » ] 评论(3) , 引用(0) , 阅读(4673) | Via 本站原创
  我司CTO和技术总监都是腾讯系的,所以我们一开始就选用腾讯云的服务。他们家的云数据库提供了可视化的运维操作页面和自动备份的能力,降低了DB运维的门槛。同时云数据库还支持高可用架构,对数据的安全性和服务的可靠性更有保障。另外有的云数据库厂商还提供了诸如数据库审计、慢查询分析、数据回档等能力,大大减轻了数据库运维和DBA的工作量。

  其实我们就没有专门的DBA,都是开发自己上去折腾,通过把数据库的可靠性外包给云端,确实极大地降低了我们的工作量,这一点还是挺爽的。但是在具体的使用过程中,发现还是有些地方不够满意,比如MySQL最高版只有5.6,没法用上5.7.8+新增的JSON字段;建立数据库自带的只读从库门槛较高(要最高版本);binlog的备份不方便;数据库授权上的坑(没有FILE和SHUTDOWN,不能grant all on *.*)等。

  记得以前对比过阿里云和UCloud的云主机磁盘IO(那时候腾讯云好像才刚起步呢),这么久过去了,再来比比看,他们的云数据库怎么样。墙内目前就只有这三家还算比较能入眼吧,网易和百度的就先跳过,都没听说谁家在用。另外那个不要脸的X云就算了,期权都能黑下来的公司,估计也活不了多久。

  这次除了对比性能,顺便再看看价格。

  在测试开始之前先打个预防针:以下的测试可能比较粗糙,并不是针对实际业务进行的,所以结果仅供参考;而且实际的业务往往并不是以性能为唯一考量标准,公司的一整套业务需要多项云服务的支撑,最基础的主机、数据库、NoSQL、对象存储、负载均衡等服务这几家都比较完善了,但是在增值、附加服务上各有优劣、亮点,实际选型还是应该根据业务特点仔细考量。


性能


  首先最重要的,是云数据库的读写性能。我在规划实例的配置时,主要考虑下面2点:首先,云数据库要使用SSD硬盘,这样能够保证数据库服务器的IO能够尽量的快。其次,云数据库的内存要尽可能大,这样有尽可能多的数据能够被缓存,提高读写速度。

  因此我选择的数据库配置如下:硬盘300GB SSD,内存8GB左右。由于每个云平台提供的配置都不相同(腾讯云的内存和磁盘比例是限定的,UCloud的内存没有8G等等),我在三个云平台上分别申请了如下配置的云数据库进行性能测试:

点击在新窗口中浏览此图片

  由于实际情况下,云数据库一般是通过云服务器进行访问的,因此我在这3个平台分别申请了配置差不多的云主机,在上面运行性能测试。我申请的云主机的操作系统都是64位CentOS 6.5,具体的配置如下:

点击在新窗口中浏览此图片

  现在比较流行的测试数据库工具是sysbench,为了和实际使用的情况吻合,我对sysbench做了参数上的修改。

  一般来说,读操作要远远高于写操作,并且有很多操作是需要范围查找和排序的,所以我在测试中提高了读操作的比例,特别是提高了范围查找和排序的比重。

  同时,对于写操作,稍微提高了update操作的比例。最终运行的测试中,每一个事务的读操作和写操作的比例是6:1左右。为了模拟项目启动之后的场景,我的sysbench测试集的数据量是总共20张表,每张表200万行数据,开启32个线程,并行向DB发送事务请求,共运行30分钟。下面是我观察到的结果:

点击在新窗口中浏览此图片

  把这个测试结果做成图表是这个结果:

点击在新窗口中浏览此图片

  这个性能测试结果大大出乎我的意料,虽然UCloud的DB界面看上去和阿里云和腾讯云相比比较朴实,产品介绍中也介绍的相对简单,但是,性能上的优势让我吃惊。说实话,自己测试之前,我没想到UCloud有如此大幅领先的性能。从测试结果分析,UCloud比阿里云高了422%,比腾讯云高了297%。而且,这还是在UCloud云数据库的内存不如其它2家大的情况下的结果(UCloud:6G内存,阿里云和腾讯云:8G内存)。
这个数据让我对UCloud的SSD云数据库性能十分动心,要知道,这个是我没有做过任何调优,开箱即用的配置,完全符合我对于云数据库“快速部署,性能满意”的期望。
 
  以下是测试结果的截图,从上到下分别是UCloud的UDB,阿里云RDS和腾讯CDB:

UCloud的UDB↓

点击在新窗口中浏览此图片

阿里云RDS↓

点击在新窗口中浏览此图片

腾讯云CDB↓

点击在新窗口中浏览此图片

价格


  看过了性能之后,我又顺便分析了一下价格,貌似阿里云和UCloud的价格是线性关系的。阿里云根据内存,CPU和磁盘定价,而UCloud根据内存和磁盘定价,CPU免费。腾讯云的配置只有几档,每一档根据内存和磁盘来定价,内存和磁盘的排列是固定的,不是简单的线性关系。因此,我计算出了阿里云和UCloud的价格因素的计算常数,然后以腾讯云的配置为基础,分别推算了3个厂商在同等条件下的价格,可以得到三个厂商的定价趋势图如下:

点击在新窗口中浏览此图片

  其中,腾讯云的价格是最便宜的,只是磁盘和内存的比例是固定的;UCloud的价格比腾讯云略贵,而阿里云比其它两家要高出40%左右的价钱。这可能是因为阿里云主备架构的关系;不过,我发现UCloud的普通版UDB和高可用版UDB几乎是一个价钱,也就是说,如果考虑主备架构的高可用版云数据库,UCloud的高可用版实例的价格比阿里云要低40%。仔细看了下,貌似UCloud的高可用数据库最近在进行促销,所以才会这么划算,也就是说趁活动期间购买的话可以省一大笔钱。可惜我们用的是腾讯云……

总结


  阿里云的文档非常全,而且详细。很多信息都可以通过文档来获取。而且它的MySQL在线管理工具很强大,就是建立DB的时候比较麻烦,还是要去界面上申请建立DB,价格较贵。

  腾讯云虽然没有阿里云的RDS做的那么完善,也还算易用。他们使用PHPMyAdmin来管理数据库,对于熟练这套工具的开发人员可能比较容易上手。价格较便宜。

  UCloud云数据库测出的TPS和QPS性能远高于业内平均水平。而且产品易用性好,价格适中。

  综上所述,性价比最高的云数据库是UCloud的UDB。

  额外再提一句,对于名列在程序员最讨厌两件事之一的“写文档”,在查看3个厂商的DB产品介绍时,感觉阿里云和腾讯云的产品介绍做的很好,里面有各种解决方案的架构,非常贴心。而且云数据库和云主机自建DB的区别也讲得很直观;而UCloud的UDB介绍比较简单,还需要进一步提高。

  以上。本文仅代表个人观点,如有意见和建议,欢迎探讨。
分页: 1/1 第一页 1 最后页 [ 显示模式: 摘要 | 列表 ]