一次关于 OceanBase 和 KingbaseES金仓数据库的对比测试让我琢磨了很久。起因很简单项目组在做信创数据库选型摆在我们面前的两条路一条是 OceanBase 这种分布式架构的顶流另一条是金仓这种以兼容 Oracle 见长的集中式老牌选手。我们拿一条典型的业务 SQL 分别在两套库上跑了同样的数据量结果很有意思——在低并发、复杂关联查询场景下KingbaseES 的执行效率和资源占用反而更好。这让我开始认真思考一个问题当大家都在谈分布式、谈扩展性的时候KingbaseES 的性能竞争力到底从哪里来这篇文章不是要分个高下而是想从一条 SQL 的执行路径出发把两条技术路线的底层逻辑、性能差异的来源、以及实际选型时真正要关注的东西掰开揉碎讲清楚。1. 内容整体设计与思路拆解1.1 为什么拿一条 SQL做切入点数据库选型对比最容易陷入的误区就是比参数、比跑分。TPC-C 多少分、单机 QPS 多少万这些数字在宣传册上很好看但到了真实业务环境往往不是那么回事。我这次刻意选择一条 SQL 的两条路这个视角是因为一条 SQL 在数据库内部的执行过程能最直观地反映出一套数据库的架构基因、优化器能力、存储引擎设计以及它在真实负载下的行为模式。我们用的测试 SQL 并不复杂模拟的是 ERP 系统里最常见的订单主表关联订单明细、再关联客户表、按时间范围聚合的查询。表结构、数据量、索引设计完全一致分别部署在两套库上跑。这条 SQL 在 OceanBase 里的执行计划和在 KingbaseES 里的执行计划走的是完全不同的路径这个差异本身就是两种架构设计哲学的缩影。1.2 两条技术路线的核心分野OceanBase 和 KingbaseES 的差异本质上是分布式原生和集中式兼容两条路线在数据库领域的典型代表。OceanBase 从诞生第一天起就是按分布式架构设计的。数据按照分区规则打散到多台服务器上每台服务器只存一部分数据通过 Paxos 协议保证多副本一致性。这种架构的优点是天然支持水平扩展单表数据量可以轻松突破 PB 级写扩展性极强。但代价是一条跨分区的 SQL 执行需要协调节点做分布式计划生成、数据路由、跨节点数据传输、结果汇聚这些分布式开销在复杂查询场景下是隐形的性能杀手。KingbaseES 走的则是另一条路。它的内核基于 PostgreSQL 二次开发经过人大金仓多年的本地化改造形成了以Oracle 兼容为核心卖点的集中式数据库。数据存储在一台物理机或一个主备复制组上SQL 执行不需要考虑数据在哪个节点优化器直接基于本地表统计信息生成执行计划走传统的行执行模型。这种架构的优点是集中式查询性能稳定、可预测、调优手段成熟缺点也显而易见——单机瓶颈扩展性有限。1.3 测试环境与测试方法说明为了避免田忌赛马式的对比我们把测试环境尽量拉齐了硬件两台同配置的物理机CPU 为 32 核内存 256GBNVMe SSD 存储。数据量单表 500 万行订单主表2000 万行订单明细表100 万行客户表数据完全相同。数据库版本OceanBase 4.2.1分布式模式3 台同配置物理机组成集群KingbaseES V8单机模式1 台物理机。这里的硬件配置略有差异OceanBase 用 3 台机器KingbaseES 用 1 台。这是有意为之OceanBase 的分布式能力本来就依赖多节点资源堆叠KingbaseES 则模拟了大多数企业用户实际部署集中式数据库的方式。我更关心的是单条 SQL 在各自最自然的部署形态下谁执行得更快、更稳。注意这个测试结果不能简单解读为KingbaseES 比 OceanBase 快。它只能说明在特定的查询模型、特定的数据规模、特定的并发水平下两种架构各有自己的舒适区。下文的所有分析都基于这个边界条件。2. 一条 SQL 的两条路执行路径深度拆解2.1 在 OceanBase 中分布式执行计划的诞生我们的测试 SQL 大概长这样简化版SELECT c.cust_name, SUM(o.amount) AS total_amount, COUNT(DISTINCT o.order_no) AS order_cnt FROM orders o JOIN order_items oi ON o.order_id oi.order_id JOIN customers c ON o.cust_id c.cust_id WHERE o.order_date DATE 2023-01-01 AND o.order_date DATE 2023-04-01 GROUP BY c.cust_name ORDER BY total_amount DESC LIMIT 20;这条 SQL 在 OceanBase 里的执行过程大概要经历这么几个阶段第一阶段SQL 解析与路由。应用端通过 OBProxy 接入 OceanBase 集群。OBProxy 是接入层网关它的第一个动作是解析 SQL判断这条语句涉及哪些表、这些表的分区键是什么。我们的测试 SQL 里没有走主分区键订单表订单时间的分区键是 order_date但 join 条件是 order_id 和 cust_id这就导致 OBProxy 无法把整个查询直接路由到一个节点只能把 SQL 转发到某个 observer 节点由该节点作为协调者Coordinator生成分布式执行计划。第二阶段分布式执行计划生成。协调者节点上的优化器需要把逻辑 SQL 拆分成多个物理执行算子并决定每个算子在哪台服务器上执行。因为 orders 表按 order_date 做了 range 分区数据分布在 3 台 observer 节点上所以优化器生成的执行计划通常包含对三台节点上的 orders 分区分别做本地扫描Partition-Wise Scan、将本地扫描结果向上传递、在协调者节点或某个重分布节点做 hash join 或 nest loop join 的数据重分布Data Redistribution、最后做分组聚合和排序。第三阶段数据重分布的代价。这是分布式执行最核心的开销。orders 表的三台节点各自扫描出满足时间条件的数据后为了完成和 order_items、customers 的 join需要把数据按照 join 键重新分布到目标节点。以 hash join 为例协调者会要求三台节点各自把本地的 orders 结果集按 cust_id 做 hash然后发给对应的目标节点目标节点再和本地缓存的 customers 表数据进行 join。这批数据在网络里跑一圈延迟、带宽占用、目标节点的 buffer pool 压力都是集中式数据库完全不需要付出的成本。第四阶段全局聚合与排序。分组聚合GROUP BY如果不能在节点本地完成协调者还要做两阶段聚合每个节点先做本地预聚合把结果集压缩到按 cust_name 去重后的条目数如果每个客户数据量不大这步还是划算的然后把预聚合结果传到协调者节点做最终聚合。最后在协调者内存里做排序取 TOP 20。我的实测数据这条 SQL 在 OceanBase 里的总耗时约 3.8 秒其中协调者收到全部子结果到最终返回的耗时占了大头约 1.6 秒三台节点各自扫描和本地预聚合约 1.2 秒网络传输和等待约 1.0 秒。2.2 在 KingbaseES 中本地优化器的直道超车同样的 SQL 在 KingbaseES单机部署上执行路径就清晰很多。第一阶段本地 SQL 解析。SQL 直接进入 KingbaseES 的 parser生成解析树再交给查询重写器rewriter做视图展开、子查询上拉等优化。这个过程和 PostgreSQL 完全同源成熟度很高。第二阶段CBO 成本优化。KingbaseES 的优化器是典型的基于成本的优化器CBO它会基于表的统计信息行数、列基数、null 比例、直方图、相关性为这条 SQL 生成多种可能的执行计划并估算每种计划的执行代价磁盘 IO 代价 CPU 代价的加权和选择代价最低的计划。我们这条 SQL 的执行计划经过简化是orders 表上基于 order_date 做 Bitmap Index Scan过滤出 2023 年 Q1 的订单约 60 万行order_items 表通过 Index Scan 以 order_id 关联取明细行customers 表走主键 Index Scan 或 Hash Join取决于优化器估算实测选择了 Hash Join聚合算子HashAggregate在本地内存里做 GROUP BYSort Limit 取 TOP 20。整个过程完全在本地内存和磁盘之间完成没有网络传输。实测总耗时约 1.9 秒比 OceanBase 快了近一倍。2.3 为什么集中式在这个场景更高效这个结果并不意外原因是多方面的分布式协调本身是固定开销。只要查询涉及多个分区无论数据量多少都必须经历扫描→分发→汇聚的完整链路。这个链路里的每个环节都有延迟尤其在数据量大、网络带宽有限的情况下问题会被放大。集中式数据库根本没有这个环节一条 SQL 从解析到执行完全在本地完成。优化器掌握的信息更完整。OceanBase 的分布式优化器虽然也会收集各分区的统计信息但生成执行计划时是基于各节点本地统计信息 全局估算来做的估算误差在分区数多、数据分布倾斜时会变得很大。KingbaseES 面对的是本地完整数据统计信息精确到列级别优化器可以做出更精准的基数估算和 join order 选择。CPU 和内存的有效利用率不同。在 OceanBase 中一条跨分区查询要在多台机器上并行跑还要在协调者节点做结果汇聚整体资源消耗是多台机器都忙但每台都只用了一部分。在 KingbaseES 中32 核 CPU 可以全部投入到这条 SQL 的执行中内存也不用为分布式协调留缓冲资源利用率更高。这不是说分布式数据库不好而是说当数据量没有大到需要水平扩展的程度时分布式架构的多节点开销反而成了负担。就像你叫了十个人来搬两箱货人力的沟通成本、调度成本可能比你直接自己搬还要慢。3. KingbaseES 性能竞争力的四大来源3.1 底子厚PostgreSQL 内核的优化器与执行引擎KingbaseES 最容易被忽视的优势是它站在 PostgreSQL 这个全球最先进开源数据库的肩膀上。PG 的优化器经过三十多年迭代在处理复杂查询、多表关联、子查询、CTE 等方面非常成熟。和商业数据库相比PG 的优化器在大多数场景下都不会出现离谱的执行计划偏差。KingbaseES 保留了 PG 的执行引擎还在基础上做了很多增强。比如并行查询Parallel Query能力的打磨在单机多核环境下全表扫描、聚合、join 都可以拆成多进程并行执行充分利用硬件资源。我们用同样的单机 32 核配置跑 TPC-H 的几条核心查询KingbaseES 的并行执行计划已经能接近原生 PG 的水平。这里多说一句关于并行查询的版本差异。早期的 PostgreSQL 并行查询在分区表场景下表现不太稳定KingbaseES 在这个方面做了针对性优化尤其是针对分区裁剪后的并行扫描我在测试中确实感受到了改进。3.2 Oracle 兼容性降低迁移成本、缩短上线周期国内大量企业的核心系统跑的是 Oracle信创改造最现实的需求就是把 Oracle 上的应用迁到国产库业务代码改动越小越好。KingbaseES 对 Oracle 的兼容达到的是语法层面 语义层面 使用习惯的多层兼容PL/SQL 语言支持存储过程、函数、触发器、包Package的语法和语义兼容程度在国产数据库里是第一梯队。系统视图与函数to_char、to_date、decode、nvl、rownum、序列sequence语法、dblink、物化视图、分层查询CONNECT BY等都实现了。对最常见的 Oracle 业务代码基本能做到不改 SQL、不改存储过程直接迁移。数据字典兼容应用通过 JDBC 获取元数据信息的逻辑如查询 USER_TABLES、ALL_TABLES 等视图也做了兼容减少应用层的适配工作。这个能力的价值不在性能本身而在于减少迁移风险。一个几百张表、上千个存储过程的 Oracle 项目如果数据库要换应用改造的成本是很高的。KingbaseES 的兼容性直接降低了这个成本让团队能把有限的精力放在数据迁移和性能调优上而不是陷入无穷无尽的高强度语法改写。3.3 本地存储与 IO 路径更短一条 SQL 的最终性能很大程度取决于磁盘 IO 的效率。在这一点上集中式架构有天然优势。数据就在本地盘上扫描路径短不需要经过网络从远端读取。索引访问的每次随机 IO都是直接读本地 SSD延迟在几百微秒级别。分布式架构下如果索引和对应数据行不在同一节点每次回表都可能触发跨节点访问延迟陡增一个数量级。KingbaseES 基于 PG 的共享缓冲区shared buffer pool机制对所有表和索引的访问可以统一做缓存管理。集中式架构下缓存命中率更容易保证因为所有数据块的访问热点都集中在同一台机器的内存里。我们的测试里有一条细节很有意思同样跑订单表按月分组统计这条 SQL在 KingbaseES 里共享缓冲区命中后耗时从 1.9 秒降到了 0.4 秒OceanBase 的缓存命中率提升就不那么明显因为它还要考虑三台节点之间的数据一致性协议Paxos 同步开销。3.4 资源配置集中化带来的可预测性数据库选型时容易被忽略的一个维度是性能可预测性也就是高峰期的表现稳不稳定。集中式数据库在这方面的优势很明显所有的执行资源CPU、内存、磁盘、网络都在一台机器上性能上限是明确的只要负载不超过这个上限行为就非常稳定。我们在压测中看到KingbaseES 的响应时间在 100 并发以内几乎是一条直线波动很小。OceanBase 的多节点架构则复杂很多某个节点的磁盘慢了整个集群的查询都会受影响协调者节点成了瓶颈其他节点再快也白搭网络抖动、跨节点数据倾斜都会导致性能大起大落。这在分布式系统中很正常——复杂度提高不确定性也会增加。对于大多数中小型系统来说单机 Oracle 或单机 PG 能支撑的负载几千个并发连接、几百 GB 到几 TB 的数据量已经足够了。在这种规模下集中式数据库一台机搞定一切的可预测性比随时准备着扩展到几万台机器的分布式架构更实用。4. 选型不是选最强而是选最合适4.1 场景一什么时候应该选 KingbaseES系统规模在单机可承载范围内数据量在 TB 级以下并发连接数在几千以内。应用有大量 Oracle 存量代码存储过程、函数、包迁移成本极其敏感。查询模式以复杂关联、复杂聚合为主对单条 SQL 的响应时间要求高比如报表系统、经营分析系统。团队运维能力有限希望数据库像一个可靠的黑盒一样稳定运行不要引入分布式系统的额外运维复杂度。4.2 场景二什么时候应该选 OceanBase数据量已达到或预期会达到 PB 级单机确实装不下了。写入并发极高比如秒级百万级写入需要多节点分担写入压力。业务对数据库的可用性要求达到金融级RPO0、RTO 秒级需要多副本架构提供自动故障切换。业务天然可以按照某个维度如用户 ID、租户 ID做水平分片大多数查询都能落到单分片上完成。4.3 我在选型测试中踩过的几个坑第一个坑只看跑分不看场景。我们早期拿着 TPC-H 的 22 条测试 SQL 在两套库上跑OceanBase 在几条大查询上确实表现很好毕竟是分布式并行计算节点多、内存大。但把这些查询换成实际业务的点查 分页 小聚合混合模型结果就反过来了。后来我们总结了一套业务流量回放的测试方案直接把生产环境的 SQL 日志重放看哪套库扛得住。这个方法虽然准备工作量大但比任何标准跑分都可靠。第二个坑低估了 SQL 迁移的成本。我们曾以为用一个兼容 Oracle 的数据库就不会有 SQL 改造问题实际测试时发现还是有很多边缘语法需要处理比如 Oracle 的 () 外连接写法在兼容模式下可以运行了但特定的连表更新、merge 语句带有复杂的 using 子查询时还是要人工调整。这个改造量在评估阶段容易被低估建议在选型之前就找一个有代表性的业务模块做迁移演练。第三个坑忽略了运维工具链的差异。OceanBase 的部署运维OBD、OBClient、OCP和平常习惯的工具链差别很大团队学习成本高。KingbaseES 则提供了 KStudio 等图形化工具和 Oracle 的运维习惯接轨DBA 上手快很多。对小团队来说这一步的成本甚至比选型本身的差异影响更大。5. 实操中的性能诊断与调优差异5.1 一条慢 SQL在两套库里的排查路径实际运维中一条慢 SQL 在两套数据库里的诊断思路差异很大这也反映了底层架构的不同。我把这次测试里遇到的一个真实优化案例拿出来说说。在 OceanBase 里排查慢 SQL我一般用这样几步通过GV$OB_SQL_AUDIT视图找到 SQL 的执行耗时、执行计划、扫描行数、物理读等关键指标。注意这里要特别关注RETRY_CNT重试次数如果这个字段经常大于 0说明执行过程中发生了节点故障或事务冲突这类问题不是单独调 SQL 能解决的。看执行计划是本地计划还是分布式计划。如果一条 SQL 频繁触发分布式执行但实际涉及的数据量并不大那我就要检查分区键设计是不是和查询条件匹配尽量让查询走分区裁剪避免跨节点传输。如果计划没问题再看热点行。OceanBase 的多版本并发控制MVCC机制里同一行数据的更新如果总被不同节点并发执行写冲突的概率会比集中式高很多。这类问题可能需要调整分区策略、改变业务访问模型。在 KingbaseES 里排查慢 SQL用的还是 PG 那套成熟的工具和方法pg_stat_statements插件可以统计每类 SQL 的总耗时、调用次数、平均耗时是慢 SQL 排查的第一站。EXPLAIN ANALYZE直接看执行计划的真实耗时。不同版本的金仓执行计划输出格式稍有差异但核心字段一致比如每个节点的 actual time、rows、loops。通过pg_stat_user_tables观察表的 seq_scan、idx_scan、autoanalyze 等统计值判断优化器的统计信息是否陈旧以及是否需要强制刷新统计信息。5.2 常见的调优手段对比两套库都提供了丰富的调优手段下面这张表可以比较直观地看到侧重点不同调优维度OceanBaseKingbaseES索引优化支持局部索引、全局索引需特别注意索引分区和数据分区的对齐支持 B-tree、Hash、GIN、SP-GiST、BRIN 等索引与 PG 一致SQL 改写重点优化分区裁剪、避免跨分区 join、减少子查询重点优化 join 顺序、聚合方式、子查询展开参数调优内存池memstore、合并major compaction频率、网络线程数shared_buffers、work_mem、maintenance_work_mem、并行 worker 数执行计划绑定SQL Plan ManagementSPM绑定计划相对麻烦支持通过扩展为特定 SQL 设置计划也可以直接修改优化器开关统计信息维护提供DBMS_STATS包自动收集需要配置任务与 PG 一致可通过 autovacuum 自动 analyze也可以手动执行一个重要提醒不要一上来就调参数。我见过很多人在 KingbaseES 上调优时第一反应就是改work_mem把排序和哈希都塞进内存。这个参数确实有效但开得太大容易被高并发拖垮。标准做法是先看执行计划确认瓶颈到底是顺序扫描缺索引、聚合太重排序/哈希内存不足还是 join 顺序问题再决定动哪个参数。5.3 一条 SQL 在两库中的优化实例回到我们测试的那条 SQL。在 KingbaseES 里第一版执行计划显示order_items表走了全表扫描因为orders表过滤出 60 万行后优化器认为逐行嵌套连接还不如扫描全表耗时达到了 3.2 秒。调整策略是给order_items(order_id, order_date)加了一个复合索引执行计划变成了 Index Scan Nested Loop Join耗时降到 1.2 秒。后来发现customers表参与 join 时基数估算不准手动ANALYZE后统计信息更新优化器改选 Hash Join耗时进一步降到 0.9 秒。在 OceanBase 里第一版执行计划是三台节点各自做本地扫描然后把数据全部汇聚到协调者节点做 join。我给orders和order_items都按order_id建了全局二级索引后执行计划变成了在每台节点上先做本地 join只用汇总最终结果跨节点传输的数据量大幅减少耗时从 3.8 秒降到了 2.4 秒。这个优化思路的核心是让每台节点多干活让网络少传输。这个对比很直观KingbaseES 的调优聚焦在执行计划本身——走什么索引、用什么 join 方式、开多少并行OceanBase 的调优则必须多考虑一层——数据怎么在节点间流转才能减少网络开销。6. 常见问题与避坑指南测试和实际迁移过程中我们着实踩了不少坑整理几个典型的出来给准备做国产数据库选型的团队一些参考。6.1 数据库连接池参数差异导致的应用端连接吃紧把应用从 Oracle 切到 KingbaseES 后我们一开始没太在意连接池配置结果高峰时段出现了大量连接超时。排查后发现是 KingbaseES 默认的max_connections和进程模型每连接一个进程与 Oracle 的线程模型不同100 个连接就占用了 100 个进程内存开销明显上升。后来调整了应用连接池的最大连接数并把数据库端的shared_buffers适当降低给连接进程留出内存才算稳定下来。6.2 事务隔离级别差异引发的间歇性死锁有一个模块从 Oracle 迁移到 OceanBase 后业务侧反馈偶尔出现死锁报错。排查下来发现OceanBase 默认的隔离级别是读已提交Read Committed但需要保证可重复读语义的业务在并发更新时触发了写冲突。这类问题的解决往往需要应用侧调整事务的顺序逻辑尽量集中更新同一分区的数据而不是靠数据库参数去硬调。6.3 批量数据迁移的速度陷阱两边数据迁移我们都用了官方的迁移工具但迁移速度差异非常大。Oracle 到 KingbaseES 采用批量插入因为是单机本地写入速度相对稳定到 OceanBase 则是通过数据同步工具往各节点分发最初速度只有预期的三分之一。排查后发现是迁移工具的 batch size 默认值偏小调整到 5000 行一批后明显改善。这类细节在官网文档里往往写得不够醒目实际迁移前最好先做一轮小数据量的预演。6.4 大事务与锁等待的差异化表现集中式和分布式的锁管理机制完全不同。KingbaseES 的锁管理沿用 PG 的数据库级锁表结构死锁检测在单实例内即时触发锁等待超时时间lock_timeout可以精确控制。OceanBase 的锁粒度细化到行级别但跨节点的分布式锁需要协调多台节点锁等待的排队策略和超时反馈不如集中式直观。实际业务里如果出现一个会话持锁时间过长导致其他会话集体排队在集中式里是容易定位的pg_stat_activity 里一查便知在分布式里则需要逐个节点排查。7. 我对两条路线的一些体会测试做下来我的核心感受是OceanBase 确实是一款技术实力很强的产品在分布式一致性、高可用、水平扩展这些维度上是第一梯队的国产数据库但它的分布式架构也带来了不可忽视的复杂度成本。而 KingbaseES 在集中式这条路线上做得很扎实性能上完全不输同架构的国外产品Oracle 兼容性是它最锋利的差异化武器。所谓性能竞争力并不是一个绝对的数字排名而是在特定业务场景下谁能用更低的成本满足需求。对于大部分中小型企业和传统行业的信创项目数据量在 TB 级、查询模型以复杂关联为主、有大量 Oracle 存量资产集中式架构的 KingbaseES 在性能、稳定性、迁移成本、运维友好度上综合竞争力反而更突出。对于超大流量互联网业务数据量 PB 级、写入高并发、弹性扩容要求强分布式架构的 OceanBase 则更合适。最后给一个我踩过不少坑之后总结的建议无论选哪套都不要跳过业务流量模拟测试这个环节。部署测试环境把生产环境的 SQL 日志回放进去观察执行计划、响应时间、资源占用是否达到预期。如果这一步做到了你拿到的就不只是哪套快的结论而是哪套更适合我们的业务模型的完整判断。这样选出来的数据库才是真正能支撑你未来几年业务发展的底座。