东莞网站域名注册,大学生创新创业大赛案例,专门做团购的网站有哪些,为什么电脑有些网页打不开自从蚂蚁金服自研数据库OceanBase获得TPC-C测试第一名后#xff0c;引起了行业内外大量关注#xff0c;我们衷心的感谢大家对OceanBase的支持与厚爱#xff0c;也虚心听取外界的意见和建议。为了让大家更好的了解测试的技术细节#xff0c;我们特意邀请了OceanBase的核心研… 自从蚂蚁金服自研数据库OceanBase获得TPC-C测试第一名后引起了行业内外大量关注我们衷心的感谢大家对OceanBase的支持与厚爱也虚心听取外界的意见和建议。为了让大家更好的了解测试的技术细节我们特意邀请了OceanBase的核心研发人员对本次测试做专业的技术解读本文为第一篇后续文章也将于近日对外发布。 OceanBase于2010年立项九年来研发人员一步一个脚印不断的对OceanBase做出改进以及增加新的功能。OceanBase也从服务于支付宝开始逐渐对外开放为广大的各行业客户提供服务。在这个过程中我们希望外界对OceanBase的实力有更直观的了解让客户对我们的产品更有信心TPC-C测试为我们提供了一个绝佳的舞台。
通过本次测试我们发现了OceanBase的一些不足之处比如之前的单机数据库只能通过增加CPU、内存等来提高处理能力OceanBase通过分布式架构可以让大量的普通硬件设备像一台电脑一样处理数据想提高性能只需增加设备即可但是OceanBase在每台设备上的性能还有不少提升空间另外OceanBase支持的功能、易用性、数据库生态相比业界标杆还有一些差距。
接下来OceanBase将在两个重点方向上发力一个是兼容Oracle数据库提供的各种功能方便客户切换使用不同的数据库另一个是提升OLAP处理能力也就是数据分析挖掘等方面的能力用同一套引擎同时支持OLAP与OLTP完善OceanBase在大数据处理方面的能力。
后续我们还将开源本次TPC-C测试工具希望与业界同行多多交流共同探讨数据库技术的发展与未来。
正文
网络上有很多介绍TPC-C benchmark的文章而且某些数据库厂商还声称自己进行了TPC-C测试还获得了单机百万级tpmC、分布式千万级tpmC等等。真实情况究竟是怎样呢
就像很多人知道的国际事务性能委员会TPC组织是数十家会员公司创建的非盈利组织TPC-C是TPC组织制定的关于商品销售的订单创建和订单支付等的基准测试标准是数据库联机交易处理系统OLTP的权威基准测试标准。TPC-C有5种事务每种事务有规定的比例分别订单支付不低于43%订单查询、订单发货和库存查询各不低于4%其余则为订单创建(不高于45%)tpmC值是订单创建事务每分钟执行的数量。
TPC-C benchmark测试必须通过TPC组织的审计准确地讲是TPC-C组织认可的审计员的审计通过审计的TPC-C的结果其完整详实的测试报告包括测试厂家、数据库版本、详细的软硬件配置、测试过程等将公布在TPC组织的网站 www.tpc.org 上。没有通过TPC的审计而擅自声称自己通过了TPC-C测试、获得XXX tpmC不仅是侵权也是不合法的。除了OceanBase目前在TPC网站上还没有看到任何一个国产数据库的TPC-C benchmark的测试报告无论是完全自主研发的还是在开源基础上修改的。
为什么TPC-C benchmark测试必须要通过TPC组织的审计呢这还得从TPC组织的诞生说起。1980年代数据库联机交易处理系统即OLTPOnline Transactional Processing出现后极大地推动了诸如自动提款机Automated teller transactionATM等联机交易处理系统的发展。每个数据库厂商都试图向客户证明自己的系统性能最好、处理能力最强但由于没有统一的性能测试标准更没有谁来监督性能测试的执行和结果发布一方面客户无法在不同系统之间进行比较另一方面数据库厂商各自的性能测试数据也没有足够的说服力。
1985年初Jim Gray联合24位来自学术界和工业界的同仁发表了名为“A Measure of Transaction Processing Power”的文章提出了一种在线事务处理能力的测试方法DebitCredit。DebitCredit定义了数据库性能benchmark的一些关键特征 定义了被测系统的功能要求而不是软件硬件本身 规定了被测系统的扩展准则即性能与数据量相匹配 规定被测系统的事务需要在指定时间内完成比如95%事务在1s内完成 把被测系统的整体成本纳入性能benchmark
DebitCredit为数据库的联机交易处理系统性能建立了统一的、科学的衡量标准后续相关的benchmark基本都以此为基础发展而来。然而一些厂商却删掉DebitCredit标准中的一些关键要求后进行测试以便获得更好的性能值这种做法现在也被一些国内数据库厂商用在TPC-C benchmark测试上这导致数据库的联机交易处理系统性能的衡量标准并没有真正统一如果说Jim Gray等人为数据库的联机交易处理系统benchmark制定的一个法律DebitCredit但却没有执法队伍来保障法律的执行。1988年TPC组织的创始人Omri Serlin成功地说服8家公司成立了非盈利的TPC组织统一制定和发布benchmark标准并监督和审计数据库benchmark测试情况才发生了根本的改变。
经过三十多年的发展TPC组织的成员超过了20个诞生和完善了数据库性能的多个benchmark标准并被全世界接受。比如TPC-C的第一个版本是在1992年发布的之后经历了多次修订以适应需求和技术的变化。为了防止厂商按自己的意愿篡改TPC-C标准进行测试以得到更高的性能值TPC组织要求所有的TPC测试结果都要经过TPC组织认可的审计员的审计审计员对测试的过程和结果进行详细的审核审计通过后审计结果连同完整的测试报告提交给TPC组织的Technical Advisory BoardTABTAB审核无异议后还将进行60天的公示公示期间如有异议厂商需要证明自己的测试符合相应的TPC标准必要时还需要再次运行benchmark测试程序。
TPC-C是对商品销售支付等实际业务系统很好的抽象。在准备TPC-C测试的过程中我们发现了OceanBase许多性能不优的地方在对这些地方进行了优化和完善后我们发现OceanBase已经达到了今年2019年双11的性能优化目标事实上TPC-C五种事务中占比最高的两种订单创建new order占比45%和订单支付payment占比43%其实就对应了生产系统中的订单创建和订单支付。因此TPC-C模型看起来很简单恰恰是这个模型对实际的联机交易处理做了非常好的抽象。
作为一个广泛接受的标准TPC-C非常严谨极大地杜绝了作弊
首先作为一个OLTP联机交易处理系统的benchmarkTPC-C要求被测数据库必须满足数据库事务的ACID即原子性、一致性、隔离性和持久性其中隔离性为可串行化隔离级别持久性要求能够抵御任何单点故障等。很显然这是对一个OLTP数据库的基本要求。在分布式环境下TPC-C的两种主要事务订单创建new order和订单支付payment分别有10%和15%的分布式事务最多可能分布在15个节点上事务的ACID对于分布式数据库是很大的挑战尤其是可串行化的隔离级别这也是至今鲜少分布式数据库通过TPC-C测试的主要原因之一。国内有些厂商混淆分布式数据库的概念把多个单机数据库堆在一起而号称分布式数据库事实上尽管每个单机数据库都满足ACID但这些堆放在一起的多个单机数据库作为一个整体并不满足ACID。
其次TPC-C规定被测数据库的性能tpmC与数据量成正比事实上真实业务场景也是如此。TPC-C的基本数据单元是仓库warehouse每个仓库的数据量通常在70MB左右与具体实现相关TPC-C要求终端用户在选择事务类型时需要按照规定的比例选择五种事务终端用户每个事务都有一定的输入时间对每种事务分别固定和一定范围的随机的思考时间一个对数函数根据这些要求每个仓库所能获得的tpmC上限是12.86假设数据库的响应时间为0。假设某系统获得150万tpmC大约对应12万个仓库按70MB/仓库计算数据量约8.4TB而TPC-C同时要求系统具备60天、每天压测8小时的存储容量因此系统的存储容量可能要30TB或更多而某些厂商用几百或几千个仓库全部装入内存无视单个仓库的最大tpmC上限然后号称获得百万tpmC不仅不符合大多数真实业务场景而且明显违反了TPC-C规范就像当年TPC组织成立之前一些公司的所作所为一样。
第三TPC-C要求被测数据库能够以平稳的性能长期地运行。测试时去掉启动预热ramp up和结束降速ramp down时间后被测数据库至少要性能平稳地steady state运行8小时其中性能采集时段不少于2小时内的性能累积波动不得超过2%。众所周知各种计算机系统在极限压力下性能会产生较大的波动并可能被压垮而崩溃为了避免被压垮实际生产环境从来不会让系统处于极限压力TPC-C这个规定正是从实际生产需求出发的。此外TPC-C要求被测数据库长时间运行同样是实际生产系统的要求。某些数据库厂商让数据库在很短时间内冲击性能的一个尖峰值既没有保证数据库在较长时间内稳定运行更谈不上性能波动不超过2%但却声称自己的数据库达到了这个尖峰性能。本次benchmark测试中OceanBase做到了8小时性能波动低于0.5%。
第四TPC-C要求被测数据库的写事务的结果必须在一定时间内数据落盘指数据库数据不是日志事实上redo log在事务提交前就落盘了对于具备checkpoint功能的数据库checkpoint的间隔不得超过30分钟checkpoint数据持久化的时间不得超过checkpoint间隔。我们理解这是为了保证数据库系统在掉电等异常情况下有较短的故障恢复时间。传统数据库的数据以数据块(例如4KB/8KB的page/block)为基本单位做到这个是把脏页刷盘。但OceanBase并非如此这是因为第一OceanBase是多副本本次测试是3副本的跨机器部署单机器异常的情况下都能够立即恢复RTO30s且数据无损RPO0并不依赖于写事务的数据落盘第二个原因OceanBase是“基线数据在硬盘修改增量数据在内存”的结构设计上是修改增量数据一天落盘一次即每日合并可根据业务量的增加而自动增加每日合并次数实际生产系统不需要也不依赖数据在较短时间比如30分钟内落盘。在TPC-C benchmark测试中OceanBase设置了checkpointing保证所有checkpoint的间隔小于30分钟并使得checkpoint数据持久化的时间小于checkpoint间隔以符合TPC-C规范。
第五业务定向优化profile-directed optimizationPDO可以提升软件的性能TPC-C也允许使用PDO但有一些限制比如采用PDO优化的版本需要在客户使用数据库厂家需要对PDO优化的版本提供技术支持等。为了避免可能出现的异议OceanBase没有使用PDO。
最后TPC-C规范虽然十分严格但依然鼓励新技术和新方法的使用比如本次OceanBase的TPC-C benchmark测试就没有像之前的TPC-C benchmark一样购买物理服务器和存储而是租用了阿里云公有云的ECS虚拟机这不仅使得扩容/缩容轻而易举还可按需租赁而极大降低实际测试成本。
原文链接 本文为云栖社区原创内容未经允许不得转载。
