如何看待阿里巴巴自研数据库性能，超越甲骨文九年前自研数据库性能？实际意义如何？

甲骨文的数据库很多年都没有参与排行评比了，这次阿里巴巴自研数据库性能是oracle的两倍（九年前性能），阿里巴巴的确顶得住双十一的客户量，但真的强大到没朋友，远远把人甩到后面了么？

热心回应 · 2019-10-12 05:07:43

虽然不是什么高热度的问题，但是还是忍不住要说一下，免得被别人带歪了方向。
首先说一下为什么甲骨文的数据库多年没有参加排行评比的问题。答主所在的公司也经常拿自己的产品去参加业内每年的测评的，所以大体上知道这是一个怎么回事。测评，实际上往往与各位想的并不一样。
测评是有专门的机构的，而这些机构本身也是有赞助商的。而一个业内的头牌老大，实际上对这类评比机构的感觉十分尴尬的。首先，对于一个使用情景，自然应该是业内做的最大最好的公司有更明确的理解。但是，由于这种公司往往并不是测评机构的主要赞助商（因为没必要），所以测评机构的一些测评标准对于这些公司来讲感觉匪夷所思。
举个例子吧，就好比你去测一个基于云计算的反病毒软件，然后你有一半以上的测评标准都是“在断网环境下如何如何”。那不管这个云计算反病毒软件多么牛，这么测评下来，结果恐怕都是惨不忍睹的（别笑，业内真事）。
那么为什么业内头牌公司不去大规模赞助测评机构，从而制定对自己有利的测评标准呢？因为这么做公关风险更高，而且头牌公司往往没有足够的动机。
公关风险方面大家自己都能领会，除非一个行业内部能够组成一个以头牌企业为主的联盟，否则这么一波操作下来很容易就被竞争对手或者测评机构内部人员给捅出来造成公关灾难。而一个产业，内部的公司之间绝大多数都是直接竞争关系，所以很难搞出一个联盟来。
再说动机方面。一般一些厂商为了体现自己在某一方面做得好，会更倾向于赞助测评机构，从而制定对自己有利的标准。但是头牌企业并没有这么做的动机，因为他们不能通过证明自己比别人做的更好，来继续开拓市场。
具体到甲骨文身上，所谓的数据库性能测试本身就有局限性。现在的数据库，已经不是随便在什么设备上安装一个软件那么简单了。很多时候数据库的部署都需要专业的硬件，以及一定的网络条件。而有时候测评标准上可能规定了必须使用多少个硬件组成集群，必须运行在什么网络环境当中，必须支持某种网络同步协议等等。如果这些标准限定的太死，与甲骨文的目标客户用例存在较大差异，那么选择不参加这类评比其实也是有道理的。
最后再提一下性能问题吧。就像这个回答说的一样：
OceanBase那么厉害，为什么不去和Oracle竞争，抢占企业市场的市场份额？网络数据库与传统的企业数据库在使用场景上有诸多不同，在这种情况下性能对比只能是做一个参考，并不能够真的拿来作为一个主要因素去考虑。所以说阿里的数据库性能超越了9年前的甲骨文，那很好。就算不超过，也不是什么大问题。就如同蛋糕上的草莓，有没有都一样吃。当然，如果有的选的话，我当然吃带草莓的。

热心回应 · 2019-10-12 05:07:44

你们根本没有明白实质意义是什么

国内现在正在逐步把系统和应用国有化，从内存、CPU、存储，到操作系统、数据库，中间层都，在政府机关和事业单位开始，已经逐步控制和迁移到国产环境了
在这个大环境下，国产的数据库，如阿里、腾讯的自研数据库，达梦（对标oracle）之类的，操作系统目前大方向是中标麒麟，服务有东方通之类的代替tomcat，CPU有兆星、海光之类的，内存有紫光…………

阿里这么一评测，就给了这个痛苦的过程给出一个完美的合理性：看，国产的数据库性能都超越原世界第一的oracle了，还有什么理由不用国产的呢？
CPU也是，现在的口径是国产的CPU已经达到了intel 大约4~5年前的水平（x86），而且海光都是基于amd的zen授权发展而来，对x86的兼容性非常好，几乎不存在迁移风险，紫光内存的DDR3已经量产了，价格也便宜，DDR4也快了。
软件？软件现在业务系统大多BS化了，换一个系统，只要浏览器能用，就能支持大部分的功能和业务。wps也适时推出了中标麒麟的适配版本
这次贸易战和华为、中兴的事真的是把之前的侥幸派打醒了
据我所知，政府机关内部应用系统都是有时间表的，需要在最近几年内完成系统和环境的迁移工作，而且对于新采购的服务器，已经原则上默认装麒麟了
今年全国已经开始登记并统计各系统迁移至麒麟和国产数据库、中间层环境预计需要多少成本，在做成本和时间评估了。

目前国内的大环境是服务器上云化（私有云、公有云都有），应用集中化、BS化，为的就是做好迁移的准备

热心回应 · 2019-10-12 05:07:45

他们还不提Oracle九年前的存储用的DRAM么，DRAM是什么，题主可以去查一下。
Oracle用的是小型机，OB是x86分布式，如果不能理解这其中的区别，就别起哄了。
九年前的硬件就差么，莫不是没用过infiniband，没用过DRAM。
非数据库业内人士说这个就算了，看到很多其他国产数据库厂商在酸的，你们是蠢还是坏呢。
OB的成绩很牛逼很牛逼，虽然Oracle如果来刷榜的话，应该能打破这个记录，但是也就只有Oracle了，其他在酸的国内厂商，你们能刷到多少tps？
--------------------------分割线----------------------------------------------------
有同学提出经济效率的比较，没想到纯吐槽还有人看，就来电正经的我的想法。
看指标经济效率的确不算优势，但是6000W每分钟，也就是100W TPS，是很少场景，按照OB的每年双十一披露的情况，前两年也是10-20W TPS的样子。对于普通用户也不需要这么大规模的集群，可能几台到几十台机器就能满足一般业务场景了，我猜这也是其他包括HP，DELL也会去测试TPCC的原因之一吧，就是你看我家机器没那么牛，但是能能做到多少的TPS，符合你们业务场景，你来买啊。
而且看扩展性，不知道OB做的怎么样，至少在其他很多分布式数据库，扩缩容一直是一个必要的特性，集群的规模按照业务增长可以慢慢加机器。
另外，如果一公司的业务做到了很高的TPS，做到一定规模量，很多都会开始自研一些组件，或者是中间件，或者基于开源的分布式数据库，去满足自己的业务需求，这也是ob为什么会存在。而且Oracle除了软件，硬件，他的服务费是很高的。
希望有更多的像OB这样，能把自研自用的数据库做成产品，拿到市场来竞争。

热心回应 · 2019-10-12 05:07:46

自从蚂蚁金服自研数据库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测试工具，希望与业界同行多多交流，共同探讨数据库技术的发展与未来。
[h1]那么通关TPC-C到底有多难？[/h1]以下是数据库OceanBase创始人阳振坤的回答。
网络上有很多介绍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组织的网站（http://www.tpc.org）上。没有通过TPC的审计而擅自声称自己通过了TPC-C测试、获得XXX tpmC，不仅是侵权，也是不合法的。除了OceanBase，目前在TPC网站上还没有看到任何一个国产数据库的TPC-C benchmark的测试报告，无论是完全自主研发的，还是在开源基础上修改的。
为什么TPC-C benchmark测试必须要通过TPC组织的审计呢？这还得从TPC组织的诞生说起。1980年代数据库联机交易处理系统即OLTP（Online Transactional Processing）出现后，极大地推动了诸如自动提款机（Automated teller transaction，ATM）等联机交易处理系统的发展。每个数据库厂商都试图向客户证明自己的系统性能最好、处理能力最强，但由于没有统一的性能测试标准，更没有谁来监督性能测试的执行和结果发布，一方面客户无法在不同系统之间进行比较，另一方面数据库厂商各自的性能测试数据也没有足够的说服力。
1985年初，Jim Gray联合24位来自学术界和工业界的同仁发表了名为“A Measure of Transaction Processing Power”的文章，提出了一种在线事务处理能力的测试方法DebitCredit。DebitCredit定义了数据库性能benchmark的一些关键特征（http://www.tpc.org/information/about/history.asp）：

定义了被测系统的功能要求而不是软件硬件本身
规定了被测系统的扩展准则，即性能与数据量相匹配
规定被测系统的事务需要在指定时间内完成（比如95%事务在1s内完成）
把被测系统的整体成本纳入性能benchmark

DebitCredit为数据库的联机交易处理系统性能建立了统一的、科学的衡量标准，后续相关的benchmark基本都以此为基础发展而来。然而一些厂商却删掉DebitCredit标准中的一些关键要求后进行测试以便获得更好的性能值（这种做法现在也被一些国内数据库厂商用在TPC-C benchmark测试上），这导致数据库的联机交易处理系统性能的衡量标准并没有真正统一：如果说Jim Gray等人为数据库的联机交易处理系统benchmark制定的一个法律（DebitCredit），但却没有执法队伍来保障法律的执行。1988年TPC组织的创始人Omri Serlin（http://www.tpc.org/information/who/serlin.asp）成功地说服8家公司成立了非盈利的TPC组织，统一制定和发布benchmark标准并监督和审计数据库benchmark测试，情况才发生了根本的改变。
经过三十多年的发展，TPC组织的成员超过了20个，诞生和完善了数据库性能的多个benchmark标准，并被全世界接受。比如TPC-C的第一个版本是在1992年发布的，之后经历了多次修订，以适应需求和技术的变化。为了防止厂商按自己的意愿篡改TPC-C标准进行测试以得到更高的性能值，TPC组织要求所有的TPC测试结果都要经过TPC组织认可的审计员的审计，审计员对测试的过程和结果进行详细的审核，审计通过后，审计结果连同完整的测试报告提交给TPC组织的Technical Advisory Board（TAB），TAB审核无异议后还将进行60天的公示，公示期间如有异议厂商需要证明自己的测试符合相应的TPC标准（必要时还需要再次运行benchmark测试程序）。
TPC-C是对商品销售支付等实际业务系统很好的抽象。在准备TPC-C测试的过程中，我们发现了OceanBase许多性能不优的地方，在对这些地方进行了优化和完善后，我们发现OceanBase已经达到了今年（2019年）双11的性能优化目标：事实上，TPC-C五种事务中，占比最高的两种，订单创建（new order，占比45%）和订单支付（payment，占比43%），其实就对应了生产系统中的订单创建和订单支付。因此TPC-C模型看起来很简单，恰恰是这个模型对实际的联机交易处理做了非常好的抽象。
作为一个广泛接受的标准，TPC-C非常严谨，极大地杜绝了作弊：
首先，作为一个OLTP联机交易处理系统的benchmark，TPC-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副本）的跨机器部署，单机器异常的情况下都能够立即恢复（RTO=30s）且数据无损（RPO=0），并不依赖于写事务的数据落盘；第二个原因：OceanBase是“基线数据在硬盘+修改增量数据在内存”的结构，设计上是修改增量数据一天落盘一次（即每日合并，可根据业务量的增加而自动增加每日合并次数），实际生产系统不需要也不依赖数据在较短时间（比如30分钟）内落盘。在TPC-C benchmark测试中，OceanBase设置了checkpointing，保证所有checkpoint的间隔小于30分钟，并使得checkpoint数据持久化的时间小于checkpoint间隔，以符合TPC-C规范。
第五，业务定向优化（profile-directed optimization，PDO）可以提升软件的性能，TPC-C也允许使用PDO，但有一些限制，比如采用PDO优化的版本需要在客户使用，数据库厂家需要对PDO优化的版本提供技术支持等。为了避免可能出现的异议，OceanBase没有使用PDO。
最后，TPC-C规范虽然十分严格，但依然鼓励新技术和新方法的使用，比如本次OceanBase的TPC-C benchmark测试，就没有像之前的TPC-C benchmark一样购买物理服务器和存储，而是租用了阿里云公有云的ECS虚拟机，这不仅使得扩容/缩容轻而易举，还可按需租赁而极大降低实际测试成本。
以下是原文链接：
数据库OceanBase创始人阳振坤：通关TPC-C到底有多难？欢迎观看OceanBase创始人阳振坤采访视频，了解分布式数据库OceanBase这十年的历程：

https://www.zhihu.com/video/1165224655283015680

热心回应 · 2019-10-12 05:07:47

1、在当前歌颂国庆的大背景下，宣传国货，是大势所趋。不可阻挡。就算有点问题，也不是现在说的时候。
2、阿里巴巴的系统不等于数据库，数据库只是构成其系统的一个环节。阿里巴巴的系统稳健与否是由他们的架构设计、软硬件实现以及运维等整体工作相关的。可以说就算有某部分出现问题，只要内部容错做得足够好，外人是看不出毛病的。所以不能因为阿里巴巴的系统没报出什么问题，就断定其数据库如何。那是外行的看法。
3、阿里巴巴可以说非常会宣传，他们选在这个节点来吹这个事，必然会很成功。很多人看破也不会说破。但是牛既然吹出去了，那下边他们自己就要圆这个事。看看后续吧！oracle和DB2等数据库是久经考验的，人家那是口碑立起来的。阿里巴巴的东西如何需要用时间来检验。

如何看待阿里巴巴自研数据库性能，超越甲骨文九年前自研数据库性能？实际意义如何？

5 个回复