KDB和Oracle的性能pk小记

在偶然的机会听到了KDB，然后带着好奇和新鲜感体验了一把这个传说中和Oracle 相似度达到99%的数据库。 　　其中一部分的驱动力在于这个活动的奖品很丰厚，参加活动后可以拿到一个iwatch，确实是很划算的一个活动。 　　而对于KDB的认识，也是在对比调优中认识到的，其实结果还是大大超出我的预期。 　　首先来简单说一下背景，我们一共十来个人，分成两队，红队和蓝队，然后红队调优Oracle，蓝队调优KDB，然后使用benchmark在同样的加压条件下的tpcc值作为参考来对比Oracle和KDB 　　乍一看Oracle这边的人很占便宜，至少调优的基准和方式方法感觉都是熟悉的，不用过多的 【KDB与Oracle性能对比】 在数据库领域，Oracle一直以其强大的功能和稳定性著称，而KDB则以其高效和灵活性吸引了不少关注。这次的性能PK活动，通过对比Oracle和KDB在相同压力条件下的TPCC（Transaction Processing Performance Council）值，揭示了两者在实际应用中的性能差异。 活动背景是在一个团队竞赛中，红队负责优化Oracle，蓝队负责优化KDB，目标是提高TPCC值。Oracle团队由于对系统的熟悉度较高，似乎拥有一定优势，但KDB团队获得了原厂的技术支持，这在调优过程中显得尤为重要。 在调优策略上，通常会涉及以下几个方面：内核调优、数据库参数调优、文件系统调优和SQL语句调优。然而，一开始，大家过于集中在数据库参数调优，忽略了其他方面。例如，Oracle团队在面对SGA（System Global Area）问题时，忽视了UNDO表空间的重要性，导致性能提升不明显。 在Oracle的参数调优中，有几个关键点值得注意： 1. 隐含参数：发现了一个可能导致性能下降的隐含参数`_fast_cursor_reexecute`，将其恢复到默认值false。 2. SGA调整：分配了30GB的SGA，但Shared Pool只有不到2GB，将其增加至10G以上。 3. PGA调整：适当调整PGA大小以适应工作负载。 4. Open Cursors：提高并发连接数，增加open_cursors和session_cached_cursors的值。 5. 审计：若无审计需求，将`audit_trail`设为none，减少不必要的资源消耗。 6. 异步I/O：启用异步I/O（filesystemio_options设为setall）和Direct I/O以提高读写速度。 7. SQL Trace：关闭不必要的SQL Trace以减少开销。 8. SQL解析：将SQL解析方式改为similar，以减少解析成本。 在硬件层面，取消了CPU超线程，从4个改为2个，以提高单线程性能。 进一步调优时，发现并发瓶颈主要在于行锁争用（row lock contention），通过增大ini_trans的值缓解这个问题。 然而，对于Redo日志的大小，团队尝试过大胆调整，发现效果并不理想，最终决定适度调整。而KDB团队则考虑到了更多的细节，如收集统计信息、检查索引设置，甚至对表进行分区，这些细致入微的优化策略使KDB在性能表现上更胜一筹。 总结来说，这次PK活动不仅展示了KDB与Oracle在性能上的差异，还揭示了数据库调优的复杂性和多样性。优化不仅仅是参数的调整，还包括对系统整体架构、资源分配、并发控制和SQL执行效率的全面考虑。KDB的优秀表现提醒我们，即使是相似度极高的数据库产品，其内在机制和调优策略仍需深入理解和实践。