排行
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
中国数据库
向量数据库
时序数据库
实时数据库
搜索引擎
空间数据库
图数据库
数据仓库
大调查
2021年报告
2022年报告
年度数据库
2020年openGauss
2021年TiDB
2022年PolarDB
2023年OceanBase
首页
资讯
活动
大会
学习
课程中心
推荐优质内容、热门课程
学习路径
预设学习计划、达成学习目标
知识图谱
综合了解技术体系知识点
课程库
快速筛选、搜索相关课程
视频学习
专业视频分享技术知识
电子文档
快速搜索阅览技术文档
文档
问答
服务
智能助手小墨
关于数据库相关的问题,您都可以问我
数据库巡检平台
脚本采集百余项,在线智能分析总结
SQLRUN
在线数据库即时SQL运行平台
数据库实训平台
实操环境、开箱即用、一键连接
数据库管理服务
汇聚顶级数据库专家,具备多数据库运维能力
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
我的订单
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
资讯
活动
大会
课程
文档
排行
问答
我的订单
首页
专家团队
智能助手
在线工具
SQLRUN
在线数据库即时SQL运行平台
数据库在线实训平台
实操环境、开箱即用、一键连接
AWR分析
上传AWR报告,查看分析结果
SQL格式化
快速格式化绝大多数SQL语句
SQL审核
审核编写规范,提升执行效率
PLSQL解密
解密超4000字符的PL/SQL语句
OraC函数
查询Oracle C 函数的详细描述
智能助手小墨
关于数据库相关的问题,您都可以问我
精选案例
新闻资讯
云市场
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
专家团队
智能助手
精选案例
新闻资讯
云市场
微信扫码
复制链接
新浪微博
分享数说
采集到收藏夹
分享到数说
首页
/
聊聊数据库基准测试
聊聊数据库基准测试
白鳝的洞穴
2023-01-06
671
昨天的文章里最后我简单聊了聊数据库测试的事情,最近也有很多用户十分关心数据库测试的问题,因为他们都在关心信创数据库如何选型的事情。前几天我和一个客户聊到信创数据库选型的时候,我的观点是对于国产数据库选型,目前一些国测的测试报告参考价值并不大。
数据库基准测试是十分困难的,因为最近这十几年我也帮助客户组织过几次基准测试,其中的苦辣,心中自知。目前很多数据库厂商都以TPMC测试数据作为其数据库性能卓越的证据。不过事实上,TPC-C测试是十分复杂的,并不是我们在自己的测试环境中跑几下子BENCHMARK工具就能得到结果的。BENCHMARK测试是成本极高的测试,需要对软硬件,网络等环境做十分细致的优化,才能够跑出好的效果。其结果的有效性也是有一套评估标准的,延时的标准差,P90/P95/P99位置的延时都是考察某个TPC-C测试结果是否有效的重要因素。这些都不是随便某个用户或者数据库厂商自己就能够完成的。而从另外一个方面来说,用户的应用系统能够在某个基础设施上跑出好的效果,TPC-C的高低实际上占的比重并不高。比如说并发能力,我曾经和一个商业银行的主管算过一笔账,他们目前的系统高峰期平均每秒交易量大约1000笔,折算为TPMC大约是6万,哪怕未来5年提升5倍,也就是30万TPMC。现在的一台国产2路服务器,跑随便哪个国产数据库,都可以轻松达到100万TPMC左右,因此对于大多数非互联网业务,TPMC都不是问题。
数据库测试是十分复杂与高成本的事情,要想比较公正的做好基准测试并不容易。十多年前我帮助一个客户对比X86服务器与小型机的效能,做过一次至强服务器与IBM/HP/ORACLE等的小型机的对比测试。当时用的是用户自有数据与测试用例。为了保证公正性,我们允许厂家做一定程度的优化,但是也颁布了十分严格的限制,比如不能使用异步提交,不能随意篡改数据,不能把REDO放到内存文件系统等。因为涉及到随后的集采,因此各个厂商也都十分重视,我甚至在一个厂商的工作区里发现了一本我几年前写的《ORACLE优化日记》,看样子这哥们是准备现学现用了。
实际上那时候X86服务器已经表现出了极其强劲的能力了,一台10万块钱不到的服务器,基本上可以和2-300万的小型机PK性能了。INTEL的哥们也不太懂数据库优化,装好系统,调完基本参数,用了不到一天就完成了我们安排的3天的测试工作。而小型机厂商都十分小心,仔细地优化每个测试用例。在分析测试数据的时候,我发现某个厂商的一组测试用例的结果有些异常,其他测试数据,小型机的结果与X86基本相当,甚至有些用例还略差,不过这组测试数据,小型机完胜X86,也完胜其他小型机厂商。从我们的数据完整性校验脚本中,也没有发现数据被篡改的情况。我突然想起了那本《Oracle优化日记》,于是让测试小组去查一下几张核心表的索引的CLUSTER FACTORY值,发现其中一张表的索引的CLUSTER FACTORY与其他企业的测试环境不同。原来这组测试用例里大多是用了索引范围扫描,为了提高性能,这个厂商把表中的数据顺序做了重排。这实际上是《Oracle优化日记》里介绍的一个优化小技巧,看来这哥们真的活学活用了。再后来我们的测试用例里就把记录顺序也作为了校验的一项内容。
数据库基准测试是测试团队与参测团队魔高一尺,道高一丈的较量,如果测试团队的技术能力不如参测团队,那么测试数据的准确性就很难保证了。现在的数据库测试里都有代码自主率测试这一项,很多企业在做数据库选型的时候也十分看中这一点。我所知道的很多基于开源代码开发的数据库产品,在一些国测中也获得了超过90%甚至95%的代码自主率测试结果。这让我十分疑惑,直到我真正看到了一份测试报告,才恍然大悟。有个基于某开源代码开发的数据库产品,代码自主率测试结果是96.3%,不过仔细阅读报告才发现,送测代码总量为93万行,送测的模块里居然没有SQL引擎,优化器等,都是一些外围模块。但是作为一般的数据库选型的用户是看不到详细的报告的,我们只能看到公布的96.3%的代码自主率。这种测试也让这些测试变得毫无意义。当然我个人的观点,代码自主率也并不是一个十分有意义的指标。
实际上用户做数据库选型更需要了解的是某个数据库产品到底好不好用,在某个应用场景是否能够很好的支撑。比如我的财务系统要用国产数据库替换Oracle,那么我想知道用友、金蝶的产品在某个数据库上跑的效果如何。数据库厂商不会提供有价值的数据,金蝶用友官方也不会告诉你这些数据。我们的国测部门能不能组织国产数据库与国产的套装软件厂家一起,做一些这方面的测试,并把测试结果公布出来呢?如果能够公布这些测试数据,那么对于用户做国产数据库选型来说,其价值远远超出现有的所有测试。如果我们想了解数据库对于复杂SQL的支持能力,那么从ERP系统的一些关键模块的性能与Oracle的对比就可以清楚的了解某个数据库产品对于复杂的SQL的支持情况。如果要了解高并发环境下并发写入能力,那么某些物联网套装软件的测试结果就很有参考价值了。
数据库
基准测试
文章转载自
白鳝的洞穴
,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
领墨值
有奖问卷
意见反馈
客服小墨