数据库性能测试---也谈PostgreSQL和MySQL的随机更新测试

 

拜读后，受老唐启发，想出下面一些问题，也许能进一步验证Pg和MySQL的性能。

1 目的：这除了对比2者UPDATE命令的性能外,更进一步考察2者整体性能.

2 为什么说可以进一步考察2者整体性能呢? 这是因为:
2.1 大量UPDATE操作,可以造成大量垃圾数据(Pg和MySQL都使用了MVCC机制来应对并发访问,只是Pg缺少MySQL的回滚段机制,致使UPDATE后垃圾元组不断增多.UPDATE相当于加逻辑删除标志并在新位置插入"新元组")
2.2 在垃圾元组不断增多的情况下, Pg的IO总量会上升, 这样数据缓存的失效可能性将增加
2.3 因此Pg的性能可能受到相比MySQL而言更大的影响(MySQL及时回收回滚段,Pg需要Vacuum定时清理垃圾元组,这样会因锁元组增加并发冲突可能并不如回滚段清理及时且减少冲突机会)

3 如果能在老唐的本次测试基础上,继续进行如下的测试,则更好且更能发现问题/说明问题.
3.1 统计测试前(已经加载好初始数据)数据的外存大小,设为t_init
3.2 各个数据库的数据缓冲区设置不大于初始数据大小,如设为30%--60%等
   (为的是考察磁盘类数据库常规环境下Pg和MySQL的性能情况,如果数据全部能加载的内存,则对比[MVCC+回滚段+缓存置换]对"系统长期运行的影响"没有意义)
3.3 根据脚本(update_non_index_commit_pg2.lua/update_non_index_commit_mysql.lua),预估更新的数据量,设为t_updated.
    如果能多次测试，把这个更新量设为初始量t_init的10%，20%，50%，100%，150%，200%，直到500%或更大一点，则更容易通过对比找出问题
3.4 统计测试结束后(已经被更新后全部刷出内存的物理存储数据)数据的外存大小,设为t_result  
3.5 分别在以上基础上增加综合性强的其他测试，如写多（TPC-C）或读多（TPC-H）测试（当然使用另外的数据集，需要检查这样的数据集所占的数据量有多少，如果较少如占比20%，则忽略不计，但注意灵活分析，确定是否可以忽略）
3.6 进行统计（可有你自己的关注点和统计方式。sysbench提供的统计结果需要参照，但不是本文重点）
    对于TPC-C：x轴为t_result，y轴3.5中得到的流量指标（Throughput,简称tpmC)
    对于TPC-H：x轴为t_result，每个t_result上的点为Q1到Q22，y轴3.5中得到的TPC-H中22条QUERY语句的值
3.7 观察结果，看看有什么不同？
    ^_^, 老唐要是能辛勤奉献这样的结果，则是一大幸事。提前感谢老唐！^_^
3.8 另外，可以观察在TPC-C/TPC-H背景下，Pg和MySQL的随机更新能力(换个角度分析)。 

3.9 期待有朋友能提供测试数据... ^_^   
   
其他
1 sysbench脚本与数据库服务器所在机器独立部署
2 原文说：
  在MySQL的测试过出现过MySQL服务器hang住的情况，出现这种情况后，无法做任何更新，过一会会恢复，但再过一会还会在hang住。上面的测试结果是取其中没有hang的情况。
  ---可以取更长的时间段，不用把hang住的情况去掉，这样测试结果能更为客观地表明真是情况。
3 如上测试场景设计，综合性较强（[MVCC+回滚段+缓存置换]+TPC-C/TPC-H），故较为贴近Pg和MySQL的整体性能实际。
4 进一步细化，可以考虑UPDATE如下的情况：
------+--------+----------------------------+----------
对比项 |主键列   | second index列(非唯一)      | 非索引列
------+--------+----------------------------+----------
MySQL |        + 设置insert buffer相关参数    |
------+--------+----------------------------+----------
Pg    +        |                            |
------+--------+----------------------------+----------
5 日志文件的大小和日志缓存的大小，不宜过大，参照生产环境的实际情况设置
6 数据文件和日志文件可以分散到不同的物理介质