【IT168 评论】在数据库领域，很有可能又一个重量级参与者来了，这就是浪潮的K-DB数据库。这个命名显然遵循了浪潮一贯的命名规则，小型机称为K1，数据库现在称作K-DB。

　　社区对K-DB有很多期待和传闻，我记录一下我的见闻供大家参考。据说10月份，K-DB将正式发布，大家所有的疑惑可能都可以解开。

　　【一封诚挚的邀请信函】

　　2015年8月30日，在浪潮北京上地的研发中心举行了一次别开生面的K-DB体验日活动，说别开生面是因为在这次活动中，浪潮公司和ITPUB社区合作，招募了10名社区技术爱好者，在现场又分为两个团队，通过同样的测试流程，展开了一次分组团队的PK。

　　在短短10天之内，论坛报名人数将近80人，大家对这次现场活动表现出了极大的兴趣，虽然最后仅仅选择了10位资深的DBA，但是大家对于一个新生的事物所表现出来的参与热情让社区对K-DB更加充满了期待。

　　浪潮发表了“一封诚挚的邀请函”，这是我见过技术领域最具诗意的邀请：

    我是K-DB ，一款数据库；
    我知道，你操作Oracle已经炉火纯青，
    我也知道，你对Oracle底层架构娴熟于心，
    但是，你对我的了解甚少，
    我想说：我和Oracle 99%兼容，性能和Oracle不分伯仲。
    你或许会怀疑，
    那么，就让我们来一场技术切磋吧！
    在Oracle和K-DB之间，由你亲自揭晓答案！
    光说不练，不是我们的风格；
    实测体验，才是我们的胆魄；
    马上加入，是您非常好的的选择；
    我们期待听到您的回应：O.K，我来了！！！
    赶紧加入我们最具实战的DBA体验活动吧！你还在犹豫什么？
    8月30日（周日），你若赴约，我必不负!

　　大家就是在这样一种期待之下，纷纷报名参与到这样一场技术人员之间的学习与切磋中的，而我则作为见证者参与了这样一场别开生面的技术交流会。

　　【一场精心准备的演示】

　　在8月30日清早，大家如期来到了浪潮位于北京上地的实验室，精心布置的会场让我精神一振，浪潮对于这次活动的重视超过了我的预期，10位参赛者的照片和介绍在环绕的显示器上分别呈现，这其中有一些非常让我意外的参与者，如恩核公司的郑保卫博士，他是行业内非常资深的数据治理和优化方面的专家，是恩核中国公司的创始人;而洪烨则来自于哈尔滨银行，他之前在IBM从事DB2的工作，后转至甲方从事Oracle和DB2等数据库管理工作。这些专家的参与，让我在活动开始之前就增添了更多的期待与好奇。

　　活动开幕之前，浪潮集团副总裁胡雷钧先生发表了感言，他是享受国务院特殊津贴的专家。作为七零后，胡总取得的成就让人仰望，在这样的活动上出场，也说明K-DB对于浪潮的K1服务器和浪潮公司的重要地位。据说浪潮参与到数据库领域，其中一个原因是Oracle目前不支持浪潮K1小型机的Unix环境，所以浪潮只好“自谋出路”，这和当年微软为了Windows而从Sybase获得SQL Server异曲同工。

　　胡总现场还展示了国内的第一张电子发票，浪潮在很多行业领域取得的成绩是无可争议的。

　　在接下来的分享中，浪潮的数据库专家介绍了K-DB的技术特点和功能，其中最引人瞩目的是K-DB的K-RAC功能，类似Oracle的RAC架构，而且据称K-RAC已经能够稳定的支撑用户的生产。

　　现场演示了插拔网线模拟故障时K-RAC的性能表现，我亲自到机房参与了插拔网线心跳中断的故障模拟和恢复过程。当然集群的测试更重要的是看前端应用的表现，现场观众在前台通过监控画面见证了集群在发生中断驱逐节点以及加入节点的过程，除了集群重配置阶段的TPMC值略有波动外，整个系统的响应非常平稳，这验证了在发生典型故障情况下K-RAC的可用性，对于一款刚刚问世的国产数据库，这非常让人惊喜，集群功能一直是非常复杂的技术，Oracle在共享存储下的RAC模式独步天下，现在K-RAC也具备了核心功能的可用性，这对于浪潮的用户来说将会非常具有说服力。

　　引用一张K-DB的集群和主备架构图，由于与Oracle数据库原理架构一一对应，大家理解起来非常简单，几乎没有障碍。

　　经过一个上午的介绍分享，大家对于K-DB的原理和工作模式都有了深入的理解，通过问答互动，也使得早前心存的疑惑纷纷解开，这一场精心准备的演示达到了良好的效果，大家开始跃跃欲试。

　　【一次热烈愉快的竞赛】

　　经过上午的学习，中午的交流，大家都熟悉起来，对于K-DB也是摩拳擦掌，下午的活动很快进入了实质性阶段。浪潮的专家介绍了测试场景，并将活动分为三个阶段：动手实测了解K-DB;分组优化进行初步测试;第二轮优化最终对比PK。

　　在动手环节，浪潮的技术人员带领大家完成了一次数据库迁移，将Oracle数据库的数据和存储过程等通过kdMigrator迁移到了K-DB数据库中，在迁移之后，原有的前端应用程序可以流畅工作，这验证了此前宣传的K-DB与Oracle数据库的良好兼容性。

　　在充分了解了K-DB之后，现场通过抽签分为了两组，5人在Oracle一组，5人在K-DB一组，大家分别以自己的实践经验调整优化各自的数据库，然后通过标准的TPMC标准测试得出双方的测试结果。所以这次活动实际上更加看重的是大家的实践能力，通过学习思考，分析优化从而得出对比结果的一场“友谊赛”。

　　测试使用Benchmark SQL工具，模拟服务器在100个Warehouse和1000个并发用户下双方数据库的性能。

　　在活动开始之前，我作为嘉宾给予了大家一点建议，其实性能之争也就是资源之争，如果两个产品的性能在同一个量级，那么更重要的就是如何充分利用CPU、内存与存储资源，达成非常好的的性能配合。而从两台测试主机的配置来看，从存储的SSD配置，到内存的256GB配备，应对100个Warehouse的测试(估计数据量不超过10GB)，存储与内存的效率都是充足的，那么在这种情况之下，最终考验的是如何充分利用CPU资源，在可比的利用率之下得出可比数据。其实整个TPMC基准测试是非常考验细节优化的，在下午两个小时左右的现场测试对比中，更重要的是考验大家对于数据库技术的理解和快速应对。

　　简要的总结一下两个阶段的优化对比，第一阶段O组的效率偏低，测试结果Oracle的性能仅有K-DB的一半;第二阶段O组经过深入调优，最终的测试结果Oracle和K-DB非常接近。整个测试过程K-DB表现出非常好的性能和稳定性，这超出了大家的预期。

　　下图是两个阶段的测试数据，这次活动更多的展现两个产品的可比性，所有的测试数据并不代表两个产品的极限性能，测试的结果也和两个团队对于数据库技术的理解和熟悉程度有关。

　　【一点现场的真实感受】

　　我在现场的真实感受就是，这是一场紧张而又热烈、开放而又友好的技术友谊赛。大家在很短的时间内组成团队，进行分工，马上就建立起团队的使命感和荣誉感，开始紧张的调优和测试。O队的队员熟悉产品，但是也承担更大的压力，务必要让优势技能落地成优势结果;K队对K-DB充满新鲜和期待，轻松上阵毫无压力的参与竞争，这让他们无形中就获得了先机。

　　对于两个阶段的比赛，我分别做了一点现场点评，现场的感觉与大家分享。

　　在第一阶段最后的测试中我注意到，蓝队已经开始调整隐含参数，_log_simultaneous_copies 这样的参数让我惊讶(我并不确定K-DB是直接忽略还是真的支持这个参数)，完全超出预期，即便在Oracle中这也是非常内部的参数和优化手段，但是更让我惊讶的是K-DB也有这样的参数。比较下来，红队这边的同事们还在修改文件大小的时候，蓝队已经开始调整隐含参数，修改大页配置，这让我为红队着急。

　　整体感觉蓝队这边动手能力很强，在开始前已经做好了准备工作，比如调整文件大小和内存配置等，而红队这边大家准备反而不够充分，所以接下来的40分钟尤为关键，是不是能够让Oracle把它的王者风范展示出来，能不能让TPMC值跑到十万以上?我建议是不是能从这边抽掉两个人换一下，把这边的成功经验复制到Oracle这边，然后看一看大家是不是能有更好的表现。

　　我刚才的一些观察，对于红队，分析问题时AWR报告都没有及时生成出来，整个优化过程有点混乱，接下来梳理一下思路然后再动手较好;蓝队这边刚才的思路就是，优化文件配置修改内存参数，然后优化隐含参数，操作系统参数，整体思路是非常清晰。大家各自整理一下思路明确方向再来一轮。OK，我们一起再来，加油。

　　在比赛最后我做了一点现场总结：

　　在今天这两次的测试过程中两队表现出了非常专业的精诚合作、团结攻关精神，我觉得非常值得钦佩。

　　我稍微思考了一下，给两队做一个命名，我觉得蓝队是可以称为暴力派，他们在两次调优过程中，尝试了N多种暴力手段，从最开始的常规配置，到调整非常内部的隐含参数，然后又去调Huge Page配置，到第二个阶段他们做什么了?搞分区，将大数据量的表改为分区表，加并行，还调整了HASH_AERA_SIZE,SORT_AREA_SIZE这些参数，还建立了新的索引，收集统计信息，他们采取了很多手段，中间数据库也重启了多次，还好稳定的跑到最后。

　　我觉得暴力派证明了两点，第一KDB是非常稳健，第二功能是非常健全的，K-DB从并行到各种非常内部的参数一应俱全，非常难得。

　　然后红队，我给大家命名为温和派。红队一直在用非常标准的手段和方法在进行调整优化。比如说通过文件的调节优化，如临时表空间、回滚表空间;一些标准参数的优化，如内存参数。红队通过可靠的常规手段进行优化，以达成非常好的实践，这在真实的生产环境中是非常重要的。红队一直在用温和标准的手段进行Oracle调节优化，所以我说他们是温和派。

　　但是温和派在第二次测试中获得了巨大的进展，在第二阶段把Oracle数据库的性能较大的发挥出来，最终结果，我们看到两个数据库在同样的场景之下的表现是非常接近的。虽然最终可能还有一些差异，原因可能有具体的一些参数原因，也有可能蓝队增加的索引起了效果，红队没有建立。虽然一些调优手段上可能会有一些差距，但是最终的结果我觉得是非常有意义的。两个数据库在同样的模型下，最后体现的性能是接近的，同一个数量级的。

　　对于今天的这个结果，第一是和我早上的预测比较吻合，我预测两个数据库会比较接近，可能大家会各有一些长处;第二是我没有想到这些暴力的优化手段K-DB都支持，就是各种功能、方法、参数，这是非常让我意外的事情。

　　有意料之中也有意料之外的事情，所以这是我的一些观点，感谢两队，谢谢。

　　【一句收获与希望寄语】

　　以下是我在活动现场发表的最后一段题外话，其中也有我的收获。

　　我最后再补充一点题外的话。

　　早上我听胡总讲到一句话印象深刻，叫“隐藏的权利感”，我想把这句话应用到两个数据库，表达一下我的观点。

　　Oracle数据库，虽然是一个商用数据库不开源，但是它又是非常开放的一个产品，Oracle几乎所有的内部操作，不管是调优的过程还是数据库的各种内部操作，都是可跟踪解析的。

　　比如Oracle数据库的启动和关闭过程，全程是可跟踪的。它的启动关闭会解析成多少个递归操作，我们全都可以跟踪出来。所以我们做Oracle DBA的工作时，面对任何事情我们都会非常有信心。Oracle开放了各种接口，方法和手段给我们，只要我们去分析研究，就能够把一个问题的Root Cause找出来，接近Root Cause就离解决问题不远了。

　　现在我们对KDB了解还不够，大家刚才都是向工作人员寻求语法支持的。以后我们加强了解，或者说我希望KDB也会变成一个更加开放接口的，更加开放Debug功能的，让我们研究这个数据库的时候也可以找到更多的乐趣。我觉得这里面找到的乐趣就是我刚才讲的或者是胡总讲的，是隐藏的权利感。就是我不动声色，但是我知道我在处理接触这个数据库的时候，我有非常强的把控力，我能撼动和解决几乎所有的问题。我觉得这一点对于技术人员是非常重要的。

　　所以将来我们加强对KDB的了解，或者KDB也做的更加灵活开放，让我们也能获得这种权利感，那我相信它的社区会更活跃更好起来，这是我最后补充的一点。

　　【一天初识K-DB】

　　一天的互动是短暂的，但是大家通过这一天的活动建立了对于浪潮K-DB的初始印象，虽然Oracle数据库是关系型数据库领域的王者，但是K-DB在基本功能方面能够达到和Oracle相近似的性能，在K-RAC的集群数据库方面，核心功能可用，这是浪潮带给参会者的惊喜。

　　对于国产RDBMS来说，我认为这是一个好的时代，因为Oracle在核心功能方面已经完全成熟，现在Oracle的更多创新来自于外围功能，核心战略也转移到软硬件一体化、云技术方面，所以国产数据库有了更充足的时间在基本功能方面追赶Oracle数据库。

　　虽然K-DB等国产数据库在产品组件上还远远落后于Oracle，但是只要核心功能能够成熟稳定，也自然能够获得足够的施展空间。

　　愿数据库领域有更多的产品成熟起来，让竞争更精彩!