• 概述与结论

    Oracle在去年引入了ECPU(相对于之前的OCPU),在前面介绍了什么是ECPU,本文则从性能的角度,看看ECPU与之前的OCPU的对比,以验证ECPU就是对应了其他云厂商vCPU的概念。

    这里选择了4 ECPU的规格MySQL.4(内存为32GB),以及 2 OCPU的规格MySQL.VM.Standard.E4.2.32GB进行对比。从如下的性能趋势图可以看到,两者表现出了几乎相同的性能。从价格上,两者的单价分别是SGD 0.050578 vs 0.055552 ( 计算0.052512+0.00304内存 ),即ECPU在该规格下,ECPU拥有几乎相同的CPU和内存,以及性能表现的情况下,ECPU规格要比OCPU规格价格要低8.9%

    (more…)
  • 重要更新

    Google Cloud Next 2024大会召开,AI是大会的核心。在数据库上,GCP也在全面拥抱AI, AlloyDB Omni 将集成AI能力、Cloud SQL for MySQL、Memorystore for Redis都会支持向量存储或搜索功能。与AWS、阿里云等云厂商一样,GCP也将推出自研的ARM CPU:Axion ARM。

    本周一下午,腾讯云控制台大面积不可用,持续近一个小时。这是自去年11月份以来,又一次云厂商大面积故障的发生。

    本周五、六,由墨天轮主办数据技术嘉年华(DTC)将在北京举行,主题是”智能•云原生•一体化—DB与AI协同创新,模型与架构融合发展”,感兴趣的可以考虑去北京现场参加。普通门票优惠价只需要9.9,买不了吃亏,买不了上当。

    云数据库更新详情

    阿里云
    • RDS SQL Serv er云盘存储容量上限增加至32000 GB,您可在新购实例或增加已有实例存储容量时按需选择 (链接1)
    Microsoft Azure
    • Azure Database for PostgreSQL正式发布支持Azure Private Link (链接2)
    谷歌云
    • AlloyDB AlloyDB Omni 版本 15.5.1 在预览版中提供 更多的 AI 功能
    • 数据库迁移服务现已全面支持从 Oracle 到 AlloyDB for PostgreSQL 的迁移
    • Cloud SQL for MySQL 现在支持在 MySQL 8.0.36 及更高版本的数据库中存储向量嵌入(预览阶段)
    • Cloud SQL for PostgreSQL(Enterprise Plus )计划内的高可用切换在秒级内完成
    • Memorystore for Redis 向量搜索功能现已在 正式推出
    参考链接

    [1]https://help.aliyun.com/zh/rds/apsaradb-rds-for-sql-server/primary-apsaradb-rds-for-sql-server-instance-types

    [2]https://azure.microsoft.com/en-us/updates/general-availability-azure-database-for-postgresql-flexible-server-networking-with-azure-private-link/

    后记

    好久没写这个系列了。从这个博客看,似乎中断了一段时间,原因是因为公司的工作调整的原因这部分,由另一个同事负责,故很长时间没有再更新。希望,自己后续能够持续的更新这个系列。

  • 什么是Oracle Cloud上的ECPU

    总得来说,海外的云是更加追求“个性”的,几乎每家云厂商都会有一堆自己不一样的概念,而实际上底层相差并不是很大。在刚刚熟悉了Oracle OCPU概念之后,在去年OCI(Oracle Cloud Infrastructure,也就是Oracle云)又推出了ECPU。最近,OCI上的MySQL也支持了ECPU。

    ECPU代表的计算或存储服务器上CPU计算核心的一定的计算能力,ECPU会逐步取代OCPU的规格模型。一个猜测是:单位ECPU就是对应某个型号CPU的core的计算能力,关于这一点,还没有找到详细的文档对这一点进行描述。

    从当前的性能与价格上来看(性能数据后续会发布),2个ECPU与1 OCPU的性能是接近的,所以,可以简单的理解ECPU就是对应于其他云厂商的vCPU。

    (more…)
  • 一个Slide介绍中,在Sysbench测试中可以通过hook的方式对一些MySQL报错进行捕获,以避免测试中断。但是做了一些搜索,对该能力并没有文档描述,故做了一些测试,以验证该能力。

    在前面的文章“Sysbench压测MySQL中遇到的”Duplicate entry”问题”中,较为详细的分析了在使用了--skip_trx=on后 ,Sysbench(版本1.0.20)在测试中遇到的”Duplicate entry”问题。也提到了,可以在脚本中添加hook的方式解决,不过之前并没有对这个方案进行验证。

    在测试脚本中使用hook的方案,在sysbench的文档中并没有找到详细的说明,这里将对这个方案做一个使用说明,并验证其有效性。我们将分两组对比测试,验证新增hook的有效性,以及新增hook后,对测试结果是否对性能有影响。

    测试结果概述

    Sysbench的该能力并没有在文档中找到说明,只是在一个Slide中看到的。本文的测试验证了如下内容:

    • 在测试lua脚本中,可以使用hook有效的避免”Duplicate entry”等报错带来的测试中断问题
    • 使用了hook之后,测试前后性能并没有观测到差异(可以认为,一般来说,发生错误的情况并不多)

    所以,后续测试中,如果不可避免的会遇到”Duplicate entry”报错(或其他报错)时,将使用hook的方式来避免。

    如何修改测试脚本

    具体的,我们在原来的oltp_read_write(sysbench 1.0.20版本)脚本中新增如下代码片段:

    function sysbench.hooks.sql_error_ignorable(err)
      if err.sql_errno == 1062 then -- ER_DUP_ENTRY
        -- do nothing
        return true
      end
    end

    完整的代码可以参考:oltp_read_write_with_hooks.lua

    具体的diff文件参考如下:

    --- /usr/share/sysbench/oltp_read_write.lua
    +++ oltp_read_write_with_hooks.lua
    @@ -21,6 +21,13 @@
    
     require("oltp_common")
    
    +function sysbench.hooks.sql_error_ignorable(err)
    +  if err.sql_errno == 1062 then -- ER_DUP_ENTRY
    +    -- do nothing
    +    return true
    +  end
    +end
    +
     function prepare_statements()
        if not sysbench.opt.skip_trx then
           prepare_begin()

    测试说明

    这里依旧使用oltp_read_write负载进行测试,测试时使用了参数 --skip_trx=on --db-ps-mode=disable --rand-type=uniform ,其中参数--skip_trx=on会带来”Duplicate entry”报错,并导致测试被终止(详细原因分析参考:Sysbench压测MySQL中遇到的”Duplicate entry”问题)。测试分两组,一组是使用原始的oltp_read_write脚本进行测试;另一组,则在脚本中新增上述hook代码。

    而后观测:

    • 使用了hook后,sysbench是否还会因为”Duplicate entry”被终止;
    nohup ./sysbench_auto.sh -l ./oltp_read_write_with_hook.lua -hYOUR_HOST -uYOUR_USERNAME -pYOUR_PASSWORD > sysbench_with_hook_with_skip.log 2>&1 &
    • 使用hook,与不使用hook,对测试结果是否有影响。
    nohup ./sysbench_auto.sh -hYOUR_HOST -uYOUR_USERNAME -pYOUR_PASSWORD > sysbench_no_hook_with_skip.log 2>&1 &

    这里的sysbench_auto.sh是一个自己编写的自动化的sysbench测试脚本。会自动化的、顺序的进行多个不同并发下的性能测试。

    测试结果详情

    没有使用hook的测试中,注意到,在并发度为48、96、128、192时候,测试被终止,而观测日志也看到了是因为“Duplicate entry”所导致的。

    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       20311|  365598|300.05|      59.09|      66.84
          8|       38195|  687510|300.04|      62.84|      71.83
         16|       71296| 1283328|300.07|      67.33|      77.19
         24|      101911| 1834398|300.05|      70.65|      81.48
         32|      131859| 2373462|300.06|      72.81|      84.47
         48|           0|       0|  0.00|       0.00|       0.00
         64|      233840| 4209120|300.09|      82.12|     101.13
         96|           0|       0|  0.00|       0.00|       0.00
        128|           0|       0|  0.00|       0.00|       0.00
        192|           0|       0|  0.00|       0.00|       0.00

    具体报错:

    FATAL: mysql_drv_query() returned error 1062 (Duplicate entry '876663' for key 'sbtest3.PRIMARY') for query

    在使用了hook的测试中,注意到,测试顺利的完成了,并没有被终止,而观察日志,也可以看到,期间也是遇到了Duplicate entry报错的,但因为hook的处理,测试并没有终止。

    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       19547|  351846|300.06|      61.40|      71.83
          8|       37524|  675432|300.06|      63.97|      74.46
         16|       70847| 1275246|300.05|      67.76|      78.60
         24|      102541| 1845738|300.06|      70.22|      81.48
         32|      132424| 2383632|300.07|      72.50|      86.00
         48|      187065| 3367170|300.06|      76.98|      92.42
         64|      234717| 4224923|300.07|      81.81|      99.33
         96|      308744| 5557409|300.06|      93.28|     118.92
        128|      341177| 6141186|300.09|     112.57|     147.61
        192|      364561| 6562115|300.10|     158.03|     211.60

    两组测试性能的对比

    根据如上性能测试数据,对QPS(Queries Per Second)进行对比:

    可以看到,整体性能波动非常小,优势在较高并发时,性能差异都小于1%;从趋势图上也能够看出来,两者几乎是重合的。

    更多测试原始数据

    2024-03-26@Benchmark on sysbench with or without hook
    host : rds_m6i_xlarge_no_hook_with_skip 
    sub_dir : rds_m6i_xlarge_no_hook_with_skip 
    ins_code : m6i.xlarge 
    ha_type : ha 
    region : tokyo 
    storage_size : 100 
    iops : 3000 
    
    sysbench for host :multiaz.cjzowaj9vqpd.ap-northeast-1.rds.amazonaws.com
    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       20311|  365598|300.05|      59.09|      66.84 
          8|       38195|  687510|300.04|      62.84|      71.83 
         16|       71296| 1283328|300.07|      67.33|      77.19 
         24|      101911| 1834398|300.05|      70.65|      81.48 
         32|      131859| 2373462|300.06|      72.81|      84.47 
         48|           0|       0|  0.00|       0.00|       0.00 
         64|      233840| 4209120|300.09|      82.12|     101.13 
         96|           0|       0|  0.00|       0.00|       0.00 
        128|           0|       0|  0.00|       0.00|       0.00 
        192|           0|       0|  0.00|       0.00|       0.00 
    
    host : rds_m6i_xlarge_with_hook_with_skip 
    sub_dir : rds_m6i_xlarge_with_hook_with_skip 
    ins_code : m6i.xlarge 
    ha_type : ha 
    region : tokyo 
    storage_size : 100 
    iops : 3000 
    
    sysbench for host :multiaz.cjzowaj9vqpd.ap-northeast-1.rds.amazonaws.com
    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       19547|  351846|300.06|      61.40|      71.83 
          8|       37524|  675432|300.06|      63.97|      74.46 
         16|       70847| 1275246|300.05|      67.76|      78.60 
         24|      102541| 1845738|300.06|      70.22|      81.48 
         32|      132424| 2383632|300.07|      72.50|      86.00 
         48|      187065| 3367170|300.06|      76.98|      92.42 
         64|      234717| 4224923|300.07|      81.81|      99.33 
         96|      308744| 5557409|300.06|      93.28|     118.92 
        128|      341177| 6141186|300.09|     112.57|     147.61 
        192|      364561| 6562115|300.10|     158.03|     211.60 
    
  • 概述

    最近,组织了一个24点SQL编程的比赛,笔者是主办方,也是评委。既然是做评委,自己也先挑战了一下,因为对MySQL更为熟悉,故选择了MySQL作为编程SQL。周末花了一些时间挑战一下,这里记录一下自己的解法以及思路。

    24点问题,是一个有趣的问题。他的扩展问题(即把牌数/计算值进行更改),很可能也是一个NP-完全问题,他与subset sum problem问题有一些些类似。如果参考subset sum problem问题的解法(例如做一些动态优化解),则可以实现还比较优的解。

    不过,这一次的比赛,是要求在一条SQL里面实现,并且限制了SQL长度为10KB,所以就大大限制了实现的方式。不过最为直接的两个思路还是,“暴力的枚举”计算和“预计算结果再做哈希求解”。即便如此,在写SQL过程中,还是遇到了如下挑战需要解决:

    • 使用单条SQL进行暴力枚举的时候,如何在没有for/while等循环控制,如何遍历所有的可能性
    • 哈希数组的空间占用比较大,可能会超过10KB,如何去压缩或者减少需要构建的数组

    另外,实现过程中,可能涉及到浮点数计算、除数为零等问题的处理,也是非常容易出错的。

    另一个角度,这些,也是这道题,有趣的地方。

    “一条SQL算24点”的题目回顾

    这次的题目,与一般意义上24点略有一些不同:

    • 首先,要求一条SQL内完成;对于穷举、哈希的实现本身就有挑战了。需要对SQL比较熟悉,否则很难写出正确、高性能的SQL
    • SQL大小限制为10KB,所以,并不能简单的穷举,简单的CASE WHEN 10KB肯定是不够的
    • 4个数字,被限制为1~10,而不是13,所以搜索空间是相对来说少了一些的,让10KB以内哈希成为可能
    (more…)
  • This content is password protected. To view it please enter your password below: