orczhou.com

testing-04

简单生活

  • 云数据库技术动态@2024-04-26

    ·

    admin

    重要更新

    IBM官宣将64亿美元收购HashiCorp（Terraform），以提供丰富的端到端的混合云平台。1 该交易已获得IBM和HashiCorp决策层批准，IBM希望将Terraform、Vault与现有的Red Hat, watsonx等产品整合，以在未来云基础设施时代，获得一块”业务高地”。

    OceanBase开发者大会发布 4.3 发版，高调进入实时分析 AP 领域2。将支持行存 & 列存一体化、新向量化引擎、物化视图等能力。

    华为云发布星耀数据库服务HRDS，与云耀云服务器HECS组成系列产品，以小规格、低成本、配置简单为特点，服务小型业务场景，如企业建站、小程序、开发测试环境等3

    阿里云

    • RDS MySQL集群系列实例新增支持跨地域备份，以更好满足合规或容灾恢复等场景。[4]
    • RDS PostgreSQL通用云盘版支持数据归档到OSS，以显著降低存储成本。[5]

    Azure(微软云)

    • Cosmos DB 中的索引建议功能正式发布[6]
    • Cosmos DB for PostgreSQL 正式发布异地冗余备份和还原[10]
    • Cosmos DB MongoDB正式发布HNSW 向量索引[11]

    GCP(谷歌云)

    • 托管PostgreSQL数据库的pgvector升级到 0.6.0 版 [12] [13] 

    腾讯云

    • 云数据库 MySQL 8.0内核版本更新，发布众多功能以提升数据库性能与稳定性，包括： Nonblocking DDL 功能、并行查询支持分区表、支持虚拟索引、 Fast Query Cache等[15]
    • 云数据库 PostgreSQL 发布 database 级别的资源隔离能力。[16]
    • 云数据库 PostgreSQL 磁盘容量最低支持10GB，同时提高了可使用的磁盘最大规格。[17]
    • 云数据库 SQL Server 国际站支持包年包月计费模式购买时长越长，折扣越多。[18]

    参考链接

  • Oracle Cloud上的ECPU与OCPU规格的MySQL性能对比

    ·

    admin

    本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。

    概述与结论

    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…)

  • 使用hook解决Sysbench压测MySQL遇到的”Duplicate entry”问题

    ·

    admin

    从一个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
    data on rds_m6i_xlarge_no_hook_with_skip
    instance configuration
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
    data on rds_m6i_xlarge_with_hook_with_skip
    instance configuration
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

  • 使用一条MySQL SQL语句完成24点计算

    ·

    admin

    概述

    最近，组织了一个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…)

  • Protected: Interview

    ·

    admin

    This content is password protected. To view it please enter your password below:

  • 杨梅树

    ·

    admin

    酸甜的杨梅，我是很喜欢吃的。这些年来到浙江后，注意到这里的杨梅比其他地方更多一写。这也算是中国，或者说江南的一大特色吧，北方人大概是吃得少的。不过因为有“望梅止渴”的故事，杨梅在中国的知名度是非常高的。

    根据Wikipeida的信息（参考），杨梅主要分布在中国的东南方地区、日本、菲律宾、朝鲜/韩国等地。在中国，又属浙江特别多，浙江又以仙居杨梅最为有名。

    杨梅酸中带甜，非常好吃。但是，杨梅的运输是非常困难的。从树上采摘下来，最佳的食用时间也就是1~3天，再长时间由于水分的流逝，味道就没那么鲜美了。再者，因为杨梅表面非常松软，而如果运输过程稍有颠簸挤压，则非常容易压坏，影响口感，也容易变质。

    所以，实际的情况就是，杨梅的上市几乎只有一个月时间，也就是说，每年只有一个月时间，也只在中国的东南方的一些城市能够吃到最好的杨梅。

    鲁彦曾经下过一篇散文《故乡的杨梅》，是啊，对于浙江人，身在外地，对于杨梅的怀念，大概就是故乡味道的怀念吧。

    前年底，妈妈离开了我们。当时，有几天闲在家里，我就和爸爸说，来年开春，我打算在后院种一颗杨梅树。去年，我们移植了一颗小的杨梅树，大概是因为种植的时候耽搁了几天。杨梅树没能够活下来。今年，我们又移植了一颗，这次的树更大一些，种植的时候我们也更小心，也了解了很多种植的知识，希望这颗杨梅树能够活下来，过几年能够吃上自己种的杨梅树。

    对于自己，对于孩子们，也希望让故乡，多一份味道。

    2022年，团队outing，在仙居的山上摘杨梅
    后院新种的杨梅树@共青城