全部产品
存储与CDN 数据库 安全 应用服务 数加·人工智能 数加·大数据基础服务 互联网中间件 视频服务 开发者工具 解决方案 物联网
云数据库 RDS 版

对比ECS自建数据库与RDS性能时的注意事项

更新时间:2017-06-27 13:36:00

适用场景

测试ECS自建数据库库与云数据库RDS的性能差异。

背景信息

很多用户都会对比ECS自建数据库与云数据库RDS的性能,但在测试两种数据库的性能时,不仅需要保证二者处于相同的环境下,如相同的网络、配置等,还需要综合考虑数据库的运行机制,否则测试结果会出现偏差且不具有说服力。

云数据库RDS作为一个公共的关系型数据库,高可用和高安全是其首要优势,其次才是高性能,因为没人会使用既不稳定又不安全的服务。RDS的优势主要体现在如下几点:

  • RDS提供了主备双节点的实例,双节点可以在同一地域的不同可用区,MySQL实例的双节点还可以在不同地域,当主实例出现故障时可快速切换到备实例,保障了RDS的稳定性。

  • RDS在数据的存取上加入了中间层,所有请求都会经过中间层,而且有SQL注入的请求都会被中间层拦截掉。在底层数据写入上,RDS采用了最高安全级别的写入,保证在主机异常掉电的情况下数据不会出现丢失。以此来保障数据库的高安全性。

  • RDS源码团队持续对MySQL进行源码优化,在标准的基准测试中性能和稳定性上都是高于社区版本的。

性能测试注意事项

当您进行ECS自建库与云数据库RDS的性能对比时,请注意如下事项。

网络差异

可用区

RDS有单可用区和多可用区之分,单可用区是的数据库主备都在同一个机房,多可用区的数据库主备可能在不同机房,所以在测试RDS的过程中需要保证ECS和RDS在同一个可用区。

网络链路

从ECS到RDS的网络链路中有多个环节,包括了ECS—>DNS—>SLB—>Proxy—>DB(如下图所示),而ECS自建数据库是ECS—>ECS,RDS的网络链路比ECS自建数据库多出了3个链路环节。

RDS访问链路

案例分析

场景:某电商要将系统迁移上云,在测试过程中发现,虽然自建库和RDS的应用代码和数据库配置完全相同,但云数据库性能较低。

原因:网络延迟放大,如下图所示。

配置差异

规格配置

RDS的规格配置主要包括了内存和CPU。在测试RDS的过程中,需要保证ECS的CPU核数与RDS的CPU核数一致。

参数配置

  • 安全配置:RDS为了保证数据的安全性,在参数配置上采用了事务提交和binlog刷写的最高保护级别。

    • innodb_flush_log_at_trx_commit:该参数指定了InnoDB在事务提交后的日志写入频率。当取值为1时,每次事务提交时log buffer会被写入到日志文件并刷写到磁盘。1是默认值,这是最安全的配置,但由于每次事务都需要进行磁盘I/O,所以有一定的性能损耗。

    • sync_binlog:该参数是MySQL的binlog日志同步到磁盘的频率。MySQL在binlog每写入sync_binlog次后,刷写到磁盘。该参数值为1时最安全,在每个语句或事务后同步一次binary log,即使在崩溃时也最多丢失一个语句或事务的日志,但因此也最慢。

  • 性能配置:RDS开放了除规格配置以外的参数供用户进行配置,绝大部分的参数都已经由官方团队优化过,用户不需要过多调整线上的参数就可以把数据库比较好的运行起来。但这些参数只是适合大多数的应用场景,针对一些特殊场景,需要您进行特殊定制。

    • tmp_table_size:该参数用于决定内部内存临时表的最大值,每个线程都要分配(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值),如果内存临时表超出了限制,MySQL就会自动把它转化为基于磁盘的MyISAM表,优化查询语句的时候,要避免使用临时表,如果实在避免不了的话,要保证这些临时表是存在内存中的。

      现象:如果复杂的SQL语句中包含了group by/distinct等不能通过索引进行优化而使用了临时表,则会导致SQL执行时间加长。

      建议:如果应用中有很多group by/distinct等语句,同时数据库有足够的内存,可以增大tmp_table_size(max_heap_table_size)的值,以此来提升查询性能。

    • query_cache_size:该参数用于控制MySQL query cache的内存大小。如果MySQL开启query cache,在执行每一个query的时候会先锁住query cache,然后判断是否存在query cache中,如果存在直接返回结果,如果不存在,则再进行引擎查询等操作。同时,insert、update和delete这样的操作都会将query cahce失效掉,这种失效还包括结构或者索引的任何变化,cache失效的维护代价较高,会给MySQL带来较大的压力。所以,当我们的数据库不是特别频繁更新时,query cache是比较好用的;但如果写入非常频繁,并集中在某几张表上的时候,query cache lock的锁机制会造成很频繁的锁冲突,对于这一张表的写和读会互相等待query cache lock解锁,导致select的查询效率下降。

      现象:数据库中有大量的连接状态为checking query cache for query、Waiting for query cache lock、storing result in query cache。

      建议:RDS默认关闭query cache功能,如果您的实例打开了query cache,当出现上述情况后可以关闭query cache。当然有些情况也可以打开query cache,以解决数据库性能问题。

案例分析

场景:某客户正在将本地的业务系统迁移上云,在RDS上运行时间明显要比线下自建数据库运行时间要慢1倍。

原因:自建数据库与RDS的参数配置不同,如下所示:

  • 用户本地参数配置:

    join_buffer_size = 128M

    read_rnd_buffer_size = 128M

    tmp_table_size = 128M

  • RDS参数配置:

    join_buffer_size = 1M

    read_buffer_size = 1M

    tmp_table_size =256K

架构差异

RDS采用了主从复制的高可用模式,同时打开了半同步复制,半同步复制是MySQL异步复制的改进,当主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待从库接收到并写到relay log中才返回给客户端。相对于异步复制,半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以半同步复制增加了事务的响应时间,详情如下图所示。

说明:SQL Server高可用模式采用mirror,同样存在上述的问题。

半同步复制原理

本文导读目录