【IT168 评论】8月30日，北京上地创业园浪潮云计算创新中心，上演了一场别开生面的数据库性能大对决，这种正面且开放式的产品性能PK，在国内数据库领域，尚属首次。那么PK双方到底是谁呢?很有意思，两个数据库产品的首字母合起来正好是“OK”，K-DB与Oracle对彪!当然你要理解成街霸中的“KO”也无不可，只是个中深意自己揣摩吧!
来历探究!K-DB数据库姓甚名谁?
很多DBA可能对浪潮的K-DB数据库不甚了解，老鱼也同样如此，在此之前老鱼对神秘的K-DB一无所知，通过网上搜索得到的信息甚少，目前能找到的比较靠谱的信息有，浪潮K-DB数据库系统由浪潮电子信息产业股份有限公司于2014-08-13在国家版权中心登记注册,登记号：2014SR119338。
K-DB，究竟是浪潮独立研发、收购还是OEM产品?浪潮一直未有明确的官方说明，这也导致了流言四起。就老鱼所知的各种版本小道消息就有四五种之多。据老鱼现场与工作人员沟通，获得的信息可以确认的一点是，K-DB是浪潮与韩国重量级企业级软件提供商Tmax公司共同研发的专为K1小机优化和定制的数据库。
至于在招募帖子中，社区有网友发帖质疑K-DB和Oracle渊源，两者皆来自同一个实验室的传闻。老鱼也现场咨询了浪潮的工作人员，其回复很强硬也很有底气："一个稍懂技术的人都清楚，Oracle的源代码外界根本接触不到，所以这种传谣根本站不住脚。"
▲K-DB11G数据库特性
一个服务器厂商为什么要做数据库?
另外一个DBA会产生的疑问，浪潮一个做服务器的厂商为什么要去做数据库?这个问题，浪潮也并未在当天的活动中进行说明，但据老鱼与浪潮工作人员的沟通，估摸着原因如下：浪潮是国内知名一家研制成功小型机的厂商，做数据库显然是为了推动自家小型机——浪潮天梭K1的销售。
目前，浪潮天梭K1不仅获得所有国产数据库厂商的支持，也已经和IBM、SAP达成战略合作关系，DB2和Sybase将为天梭K1提供支持和优化。但数据库领域绝对霸主Oracle以一贯的“高冷”范儿，在一些版本上对K1的支持不是很好。
众所周知在高端服务器、小型机市场。中国重要行业领域，例如金融、电信、能源、交通等行业的大型信息系统广泛使用国外厂商，如IBM的小型机、Oracle数据库、EMC存储设备等，也就是我们俗称的“IOE”。就当前国内的趋势来看，去“IOE”已经是大势所趋，跟早几年前不同，现在大多探讨的已经不是去不去的问题，而是什么时候去的问题。显然K1能替代IBM小型机，却一直无法解决大量小机用户对Oracle数据库的需求，而Oracle在一些版本上对K1的支持不是很好，浪潮只有转向其他数据库，于是就有了与Oracle相似度达到99%的K-DB诞生。
老鱼观摩上午场 K-DB也支持集群
言归正传，30日，老鱼早早的就赶到了活动现场，现场的布置让老鱼眼前一亮，相当洋气，有木有黑客马拉松的那种科技范?
9点，DBA们开始陆续到场签到，举办方为参赛的DBA准备了早餐和一件印有O.K的T恤，相当贴心。签到的DBA中，熟人不少，盖国强老师首先登场，盖老师是作为本次活动特邀嘉宾出席，而非参赛选手哦!还有老朋友恩核总经理郑保卫也来了，老鱼采访过他多次，郑保卫是个非常热心的人，老鱼有什么数据库方面的问题，只要向他请教都能得到迅速仔细的解答。
▲特邀嘉宾盖国强签到(左)恩核总经理郑保卫签到(右)
参与这次PK赛的DBA皆来自于ITPUB社区的招募，经过DBA自主报名，社区筛选最终组成10人的测试体验团队，这里老鱼要说的是，社区筛选要求还是比较严格滴，要求报名的DBA必须具有Oracle大型生产环境管理维护3年以上经验，从事过专职Oracle DBA职位，且拥有OCP及以上认证。(PS：小广告下，ITPUB国内最大的DBA社区，欢迎您的加入!)
▲参赛DBA合影，DBA都是很精神的帅小伙
前期通过与参赛选手简单的沟通，老鱼发现绝大多数DBA对K-DB知之甚少，那PK前，势必要让参赛队员了解K-DB数据库，因此整个上午的活动环节分别由浪潮信息高端产品部副总经理江豫京做K-DB产品介绍，浪潮信息解决方案部资深架构师金学东做K-RAC演示操作。
▲浪潮给参赛DBA介绍K-DB数据库
▲浪潮信息解决方案部资深架构师金学东做K-RAC演示
▲体验“K-RAC”功能，现场邀请盖老师去完成破坏性测试
从介绍来看，K-RAC和Oracle RAC较像，浪潮工作人员现场演示了热插拔，并邀请盖老师进行了破坏性测试(亲手把网线拔下来)，从前端展示的曲线图可以看到性能出现短暂波动，之后保持持续且稳定的运行，尤其值得注意的是，主机恢复后还能重新构建集群，恢复原有负载，从现场的演示看，稳定性相当不错。
▲K-RAC热插拔前端展示曲线图1
图1展现的内容为K-RAC两台服务器正常运行的状态。可以从图中了解到，kac1、kac2两个节点都有请求输入并正常执行。
▲K-RAC热插拔前端展示曲线图2
图2展示当心跳线拔出后，可以看见只有 kac1有请求输入，kac2节点是未激活状态。表明心跳线拔出后kac2节点宕机，只有kac1节点工作。
▲K-RAC热插拔前端展示曲线图3
图3展现的是因心跳线拔出kac2节点宕机后，kac1节点进行Fail-Over的过程。在kac1节点重建集群并进行恢复的过程中会出现短暂的请求拒绝的过程，这时发往kac1节点的请求因无法处理而出现短暂堆积的过程。此图展现的就是kac1进行Fail-Over的过程中，因无法处理业务而在堆栈中短暂出现请求等待的情况。
▲K-RAC热插拔前端展示曲线图4
图4展现的是kac1在重建集群与Fail-Over完成后，重新正常处理请求，并处理完堆栈中等待的请求的过程。可以看到请求列表中已经基本上没有等待的执行中的业务了。
经过亲身体验及现场大屏显示的监控效果，盖老师非常惊讶!K-DB不仅能够支持集群(K-RAC)，且能够流畅的运行，数据恢复的也很快。盖老师认为对于数据库来说，能够真正做到集群的应用是非常复杂的，可以说集群数据库的复杂性远远超过单机的数据库版本。其实国内有些厂商也做类似于集群的选件的产品，但有很多问题。盖老师认为K-RAC能够流畅运行，这本身就是一个奇迹。
虽然出席活动，但盖老师点评还是相当严谨：“至少在演示的过程中，K-RAC整体表现非常流畅。如果它能够在生产环境中能经受住生产的实际考验，那这款产品带给用户的，一定会是惊喜。”
郑保卫体验后表示，K-DB在破坏性测试中，K-RAC能流畅稳定运行，当网线插上去后，性能没有出现非常大的浮动。而且不管是从K-APM监控或者是从K-DB DBMS Admin功能的监控，两个性能都非常稳定，这是非常难做到的。K-RAC里面的原理和机制，其实是非常完善的。而且K-DB的I/O进程性能优化做的不错，单机1000以上的在线用户时性能比Oracle要好些。
高潮迭起 老鱼观摩下午场
下午首先开始的是动手环节，首先是DBA们尝试使用K-DB迁移工具，实现Oracle 到 K-DB的无缝迁移。需要说明的是，在招募环节，主办方就早早放出话“为体现一键迁移的真实体验感，参会的DBA朋友需要自备迁移数据。”要玩就玩真的，所以在这个环节开始前，现场的10名DBA就已经完成了自己所带的数据技术准备，在现场K-DB技术顾问的帮助下，大部分DBA迁移都进行的比较顺利。在开始的10多分钟，老鱼就听见有DBA说迁移成功，但也有DBA没有迁移成功，未成功原因不明，老鱼未来得急采访。(事后老鱼打听原来是当天现场的网络不太给力，看来以后类似的活动，建议主办方可以多开辟几条网络专线。)
▲一键迁移功能体验
迁移体验结束后，接下来开始的就是最激动人心的PK环节。既然是PK对抗，那么就要分组，红蓝两队分别由5位DBA组成，团队分组由现场抽签决定，红蓝两队各选举一位团队Leader，负责每个团队的任务分工，红队队长由来自哈尔滨银行的洪烨担任，蓝队队长是郑保卫。为了各组尽快熟悉环境，每组配置1位辅导老师帮助解决环境问题，老师可以解答调优参数对应映射的问题，但不能解答性能优化相关问题。
比赛环境如下：
比赛任务要求：
使用Benchmark SQL测试工具模拟服务器在100个Warehouse和1000个并发用户下双方数据库的性能。
每个团队会有一台笔记本直接连上大屏幕，实时显示调优的状态，参数调优过程需要在该笔记本上完成;团队其他队员可以用自己的笔记本查看数据库状态，但不许做调优操作。
调优比赛分两阶段进行，每次调优结果为40分钟，完成后由每队辅导老师启动Benchmark SQL和nmon或topas监控数据库服务器的状态，并以运行5分钟后的屏幕显示结果为最终结果。
原则上不限制调整服务器及数据库的任何参数，但考虑到调优的参数应符合实际应用状态，不能使用破坏数据一致性的参数，比如 _disable_logging = true
每阶段完成后由盖国强对双方的调优做点评，比赛最终评判以两次调优的成绩优异作为比赛的最终结果。
比赛结果会记录以下参数：
1.TMPC ： 来自Benchmark SQL
2.CPU%： 记录处理器使用率
3.IO% ： 记录磁盘IO使用率
4.Network%：记录网络带宽使用率
第一轮PK结果惊爆一地眼球，盖国强点评及部分人员调换
乍一看Oracle组似乎很占优势，至少调优的基准和方法都是DBA们所熟悉的，且无需花费时间去额外熟悉K-DB。而对K-DB组来说，也未必没有优势，虽然对K-DB不是那么了解，但因为两队都有专门的老师来提供额外的辅助，辅助老师来自浪潮，原厂你懂的!
▲红队(O组)在紧张的调试中
现场测试环境里面布满了各种性能陷阱，各组要在有限的时间内对数据库进行性能调优，将TPMC值跑得更高，对DBA们来说还是有相当大的挑战性的。DBA对数据库性能调优的理解是否足够透彻，能否快速的分析问题，都要在短短的40分钟经受考验。性能最大化的展现，除了产品需要有优质的基因外，DBA人的因素也至关重要。
▲2轮PK结果
经过40分钟紧张的调优，第一轮PK结果出来了，结果惊爆一地眼球，K-DB居然比Oracle快一倍?现场一片哗然!这个结果实在出乎意料。难道众目睽睽下作假不成?所谓外行看热闹，内行看门道，为什么会是这个结果?我们听听盖老师的分析。
▲盖老师点评
盖老师一针见血的指出这个结果产生的原因，K组里乙方人员较多，而O组里甲方人员较多。(这意味着K组在性能优化方面更加擅长)，从现场可以看出来K组调优水平比较高，隐含参数都调到了。而O组则显然不够熟练，调优还在较浅的层面。
第二轮PK开始前，盖老师给红队建议，在第二轮可以更“大胆”点，不要掉以轻心。结果第二轮开始时，红队明显调整了优化策略，优化手段也更放得开。毕竟都是操作优化Oracle多年的老手，红队调优性能很快就上来了。
第二轮跑分结果比较相似，K组TPMC(92085)，O组(89052),显然K-DB的性能还是略胜一筹。当然这并不能说明K-DB就比Oracle更强大，在有限的时间内，DBA没有充分发挥出Oracle的优势也是一方面的原因。
盖老师对第二轮点评很诙谐，戏称，K组是暴力派，O组是温和派。为什么这样说?从现场调优手段看，K组调优手段明显更多样化，改分区，改并行，建索引，大页调整等等。盖老师称：“我没有想到这些暴力的手段，K-DB都支持，这让我非常意外。”
而O组显得更温和，多用一些非常标准的手段和方法去调优。但是温和派在两次测试中取得了巨大的进展，尤其是在第二阶段把Oracle数据库的性能较大的发挥出来，最终结果我们看到两个数据库在同样的场景之下的表现是非常接近的。
DBA们是怎么看K-DB?
经过2轮对比测试，盖老师称，K-DB的表现很稳健，功能也很健全，PK结果既在预料之中也是意料之外，但褒奖K-DB的同时，盖老师也给出了建议，Oracle虽是个商用数据库并不开源，但它是非常开放的。不管是调优的过程还是数据库的各种操作过程，全部都是可跟踪可解析的，这让DBA面对任何情况时都会非常有信心。
K-DB在经受住健壮性、易用性的考验之后，应该更加的去考虑如何向社区提供更开放的接口。不管是文档、方法还是工具，让大家更快的更深入的理解这款产品，创造一个良好的生态，获得广泛的生命力。盖老师认为这对于一款数据库产品来说，这是至关重要的。
而蓝队队长郑保卫在总结时表示：“今天的竞赛过程中我一直在用甲骨文的思维与理解在调优K-DB，通过体验发现，O和K很像。甲骨文的一些资源和参数，发现都可以用上，真的挺惊讶。K对O记的DBA来说很容易上手”。
郑保卫对K-DB的性能优化器大加赞扬，郑保卫称：“K-DB的性能优化器做得非常敏感，当我通过修改一些参数，包括用SQL语句上的提示来改变它的要素，K-DB的优化器能很快的识别到，这一点是非常不容易的。K-DB能做到的程度的确让人惊讶。K-DB的外连接处理的也非常不错，这是其他数据库厂商无法实现的，说明K-DB的技术成熟度非常高。”
与盖老师相同，郑保卫也人为，K-DB相比Oracle的短板是生态圈。郑保卫称，在管理性上，K-DB不及Oracle，因为这是一个生态体系建设问题，Oracle已经做了很多年，它构建了一个非常庞大的生态体系。这个不是技术上的问题，K-DB可以以数据库为中心逐渐去发展更多的合作伙伴，包括第三方工具来构建生态链的，慢慢去发展，很快也会构建起来。
红队队长洪烨总结则显得很谦虚，首先表达了惭愧之意，没有将Oracle性能最大程度展现出来，最后还是差了那么一点。其次重点赞扬了队友非常给力，最终达到一个跟K-DB非常接近的一个指标。洪烨称随着对K-DB慢慢了解，发现其内部的很多机制与Oracle相似度很高，执行命令和操作上相似度也很高。对一直操作Oracle的DBA来说， K-DB操作很容易学习，也很容易上手。最后洪烨表示对主办方表示感谢，称在今天这个活动中学到了很多。
到此，本次数据库PK竞技就到了尾声。最后主持人的一句话，老鱼觉得挺到位的，PK结果并不重要，短短两个小时之内找到这么多问题，其实已经殊为不易。作为一个数据库的技术人员，想在这个领域走的更远，就需要不断的学习去了解更多的知识，不断在各自工作岗位中去提升自己的能力。
小结
一天下来，虽然是观摩，但也挺累的，但对来老鱼来说，收获也是颇多。首先老鱼要为此种开放式的产品对比PK模式点个赞，因为从感官上讲更加直观，是骡子是马拉出来遛遛，而不是光说不练。其次现场竞技，不仅仅是对数据库产品的一种考验与信心的展示，也是对DBA的一种考验，相信参赛的DBA也不枉此行。另外，通过这场PK，可以肯定一点是，K-DB在处理OLTP业务方面已经与Oracle不分伯仲。浪潮的闯入，能给数据库领域带来一丝新的活力吗?老鱼认为有选择才有性价比，如果一个数据库领域被一家独霸，那是不会有任何性价比可言的。
