OceanBaseVS金仓：一场关于架构哲学与实战性能的深度对话前言：为什么这两货会被拉到一起比？很多人聊到国产数据库

前言：为什么这两货会被拉到一起比？

很多人聊到国产数据库，特别是OceanBase和金仓的时候，总喜欢把它们放在对立面比来比去。其实在我看来，这两货根本就不是同一个赛道的选手。这篇文章聊聊我这两年的实测体会，特别是从架构效率、场景优化、资源消耗、运维成本这几个角度，看看金仓（KingbaseES）到底是怎么在特定场景下跟OceanBase的比较。

先给家人们交代下背景。博主负责数据库选型和运维这块儿。这两年信创替代的活儿一个接一个，手里同时管着OceanBase和金仓两套系统。说实话，一开始我也觉得这两个东西有可比性，但用着用着就发现，它们的设计完全不同。你像OceanBase走的是分布式路线，基于Paxos协议搞多副本，数据自动分片，天生就是为了互联网那种高并发、弹性扩展的场景设计的。而金仓呢，走的是传统集中式或者共享存储的路子，更像是把传统关系型数据库做到极致，然后再通过集群、读写分离这些方案来提供高可用和扩展性。

在这里插入图片描述

上面这种架构上的根本差异，就会直接导致了它们在延迟、复杂SQL处理、资源消耗、运维成本这些维度上的表现截然不同。这篇文章博主就从实际测试和运维经验出发，聊聊这些差异。

一、架构哲学：走了两条完全不同的路

要搞明白金仓和OceanBase在性能上为啥差这么多，就得先从架构给大家说说

OceanBase的Paxos分布式架构

说说OceanBase，它底层用的是Paxos协议搭建的分布式架构。说直白点，就是把完整的数据拆成好多小块，每一小块再做几份副本，分别存到不同的机器上。咱们往里面写数据的时候，Paxos协议有要求，得大部分副本都确认写入成功才行。比如3个副本的话，至少得有2个返回没问题，这次写入才算真正完成。

这种架构的好处，其实挺明显的。首先就是可用性高，单台机器出故障挂掉了，数据不会丢，服务也能正常跑，基本不受影响。第二是扩展起来方便，想扩容直接加机器就行，理论上想加多少台都可以。第三是能做异地多活，副本可以部署到不同机房，用来做容灾。

但它也不是没代价的，最主要的问题就是延迟。毕竟每写一次数据，都得通过网络去协调好几份副本，这个网络来回的开销，是怎么都躲不掉的。放到金融交易这种对延迟特别敏感的场景里，这点开销带来的影响，可就不是小事了。

金仓的集中式/共享存储架构

再来说说金仓KingbaseES，它走的是完全不同的另一条技术路线。它既可以用传统的集中式部署，也能搭建共享存储集群，也就是大家常说的KES RAC。集中式模式的话，数据主要都在单个节点上完成处理；共享存储模式呢，是好几个节点共用同一份存储，但每个节点都配有自己独立的计算资源和缓存。

这种架构的特点其实挺突出的。第一点就是延迟低，数据处理的路径更短，没有那些分布式协议带来的额外开销。第二点是一致性强，共享存储本身就天然保证了数据的强一致性。第三点就是成熟稳定，经过这么多年的打磨，在金融、政务这些核心场景里，都已经验证得比较充分了。

在共享存储集群模式下，金仓通过全局缓存融合技术，让多个节点访问共享存储上的数据时，体验就和访问本地数据差不多，同时还能保证数据的一致性。这种设计放在写密集型场景，或者对一致性要求很高的场景下，优势会特别明显。

架构带来的延迟差异

其实这个差距是架构层面的，不是说你调几个参数就能完全弥补回来的。

为啥这么说呢？你想啊，OceanBase的Paxos协议，要求每次写入的时候，至少得跨网络同步2个副本才算完成。这个网络来回的时间，也就是咱们常说的RTT，直接就定死了它的延迟下限，再怎么优化都低不过这个数值。

而金仓的共享存储架构呢，数据访问的路径要短得多，根本没有这种分布式协议带来的额外开销。

打个比方吧，就好比从北京寄快递到上海。OceanBase的做法是先送到中转站，中转站再分发到最终目的地，时间自然就长了。而金仓的做法是直接从北京送到上海，速度当然要快不少。

二、复杂SQL执行效率：金仓的“主场优势”

那么接着往下说啊。刚才聊的那些，其实说的都是架构层面的东西，架构定下来了，性能的天花板基本也就定了。但天花板归天花板，底下还有个地板呢，这个地板指的是什么呢？就是你跑复杂SQL的时候，实际效率到底能有多少。

这块我得单独拎出来说说，因为金仓在这方面的表现，确实让我挺意外的。

怎么测的呢？我们当时搭了一套统一的测试环境，尽量保证两边的硬件条件差不多，这样对比起来才有意义。

硬件配置上呢，OceanBase那边是3个节点，每个节点配2颗CPU、128GB内存。金仓这边是2个节点的共享存储架构，每个节点的配置也是2颗CPU、128GB内存。也就是说，两边的单节点配置是一样的，只是节点数量不同，这个也符合它们各自架构的特点。

测试工具用的是sysbench加上我们自己写的一套业务SQL。为啥要加自定义SQL呢？因为纯sysbench测出来的结果，往往和真实业务差得挺远的，参考价值有限。我们自己写的那些SQL，都是从实际生产环境里摘出来的，包括多表关联、聚合统计、排序分组这些比较重的操作，这样测出来的结果才更有参考性。

多表关联

俺们来做个测试，第一个测试是模拟对账场景，需要关联账户表、交易流水表、客户信息表，进行汇总计算：

-- 测试SQL：多表关联对账查询
SELECT 
    c.customer_name,
    a.account_no,
    SUM(t.amount) AS total_debit,
    SUM(t.amount) AS total_credit,
    COUNT(*) AS transaction_count
FROM 
    sys_customer_info c
JOIN 
    sys_account a ON c.customer_id = a.customer_id
JOIN 
    sys_transaction_flow t ON a.account_id = t.account_id
WHERE 
    t.trans_time BETWEEN '2025-01-01' AND '2025-12-31'
    AND t.status = 'SUCCESS'
GROUP BY 
    c.customer_name, a.account_no
HAVING 
    SUM(t.amount) > 1000000
ORDER BY 
    total_debit DESC;

这个查询涉及三个大表的关联，还有分组和聚合。测试结果：

数据库	执行时间	行返回时间	执行计划特点
OceanBase	42.5秒	2.1秒	分布式执行计划，跨节点数据传输
金仓	18.7秒	1.3秒	本地执行，优化器选择了哈希连接

为什么会有这么大差距？我看了两者的执行计划，发现问题出在数据分布上。

OceanBase把这个表按主键 hash 分区后，分布在3个节点上。执行这个查询时，需要先在每个节点上本地聚合，然后汇总到汇总节点再全局聚合。这个跨节点数据传输的开销，在数据量大的时候特别明显。

而金仓虽然也是2节点共享存储，但优化器可以选择在一个节点上完成大部分计算，只需要访问一次共享存储。执行计划显示，金仓选择了哈希连接，并且利用了多版本并发控制（MVCC）特性，避免了锁等待。

嵌套子查询：金仓的“魔法”

第二个测试是查询有异常交易行为的客户（子查询嵌套）：

-- 测试SQL：嵌套子查询查询异常交易
SELECT 
    customer_id,
    customer_name,
    risk_level,
    total_transactions
FROM 
    sys_customer_risk
WHERE 
    customer_id IN (
        SELECT 
            account_id 
        FROM 
            sys_account
        WHERE 
            account_status = 'NORMAL'
            AND open_date < '2023-01-01'
    )
    AND customer_id IN (
        SELECT 
            customer_id
        FROM (
            SELECT 
                customer_id,
                COUNT(*) AS txn_count
            FROM 
                sys_transaction_flow
            WHERE 
                trans_time BETWEEN '2025-01-01' AND '2025-12-31'
                AND trans_type = 'CROSS_BORDER'
            GROUP BY 
                customer_id
        ) t
        WHERE 
            txn_count > 10
    )
    AND risk_level > 'MEDIUM'
ORDER BY 
    total_transactions DESC;

这个查询有两层嵌套子查询，还有聚合和分组。测试结果让我挺意外：

数据库	执行时间	结果集大小	优化策略
OceanBase	38.2秒	1,245条	子查询拆分，分布式执行
金仓	14.6秒	1,245条	子查询展开，物化中间结果

金仓的优化器在这里做了一个很聪明的决策：把子查询展开，并且将中间结果物化。它先执行了内层子查询，把符合条件的客户ID列表物化到一个临时表中，然后再用这个临时表去关联外层查询。这样就避免了重复扫描大表。

OceanBase则因为分布式执行计划的复杂性，无法做这种优化。它需要把子查询也分布式执行，然后在汇总节点合并，这个过程的开销在数据量大时非常可观。

窗口函数：金仓的“杀手锏”

第三个测试是计算客户的滚动交易排名（窗口函数）：

-- 测试SQL：窗口函数计算滚动排名
SELECT 
    customer_id,
    transaction_date,
    amount,
    ROW_NUMBER() OVER (
        PARTITION BY customer_id 
        ORDER BY transaction_date DESC
    ) AS daily_rank,
    SUM(amount) OVER (
        PARTITION BY customer_id 
        ORDER BY transaction_date 
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS rolling_7day_total,
    LAG(amount, 1) OVER (
        PARTITION BY customer_id 
        ORDER BY transaction_date
    ) AS prev_day_amount,
    LEAD(amount, 1) OVER (
        PARTITION BY customer_id 
        ORDER BY transaction_date
    ) AS next_day_amount
FROM 
    sys_customer_transactions
WHERE 
    transaction_date BETWEEN '2025-01-01' AND '2025-12-31'
    AND amount > 10000
ORDER BY 
    customer_id, transaction_date;

这个查询用了ROW_NUMBER、SUM、LAG、LEAG等多种窗口函数，还有复杂的分区和排序。测试结果：

数据库	执行时间	内存使用	特点
OceanBase	56.8秒	高峰8.2GB	窗口函数分布式执行，需要跨节点排序
金仓	23.4秒	高峰4.7GB	本地排序，优化器优化了窗口函数计算

窗口函数在分布式数据库上是个老大难问题。因为窗口函数需要基于特定的排序和分区，这在分布式环境下意味着要么全局排序（需要汇总所有数据），要么在每个节点上局部计算再合并（可能不准确）。

OceanBase选择了分布式执行窗口函数，这需要跨节点数据传输和全局排序，开销很大。而金仓可以在一个节点上完成所有窗口函数计算，利用本地排序和缓存，效率高得多。

三、资源消耗：看不见的成本

除了看得见的性能，资源消耗也是数据库选型的重要考量。我们做了一个7天的资源监控对比：

CPU使用率对比

在业务高峰期（9:00-18:00），我们监控了两种数据库的CPU使用率：

# 监控命令示例
while true; do
    top -b -n 1 | grep "Cpu(s)" >> cpu_usage.log
    sleep 60
done

时间段	OceanBase平均CPU	金仓平均CPU	差异原因
9:00-12:00	72%	48%	OceanBase需要处理分布式协议开销
12:00-14:00	65%	35%	OceanBase副本同步，金仓本地处理
14:00-18:00	78%	55%	OceanBase跨节点数据传输，金仓本地缓存
18:00-22:00	62%	42%	OceanBase后台合并，金仓轻量级后台任务
22:00-9:00	38%	28%	OceanBase日常维护任务较重

金仓的平均CPU使用率比OceanBase低20-30个百分点。这意味着什么？意味着在相同的硬件条件下，金仓可以承载更多的业务量，或者你可以用更低的硬件成本达到相同的性能。

内存使用对比

内存方面，两种数据库的策略也不同：

内存指标	OceanBase (3节点)	金仓 (2节点)	说明
总内存配置	384GB (每节点128GB)	256GB (每节点128GB)
高峰期使用	310GB (81%)	142GB (55%)	金仓内存效率更高
缓存命中率	92.4%	98.2%	金仓本地缓存更有效
内存碎片率	12.5%	4.2%	金仓内存管理更精细

OceanBase因为需要维护多个副本和分布式元数据，内存开销更大。而金仓通过精细化的内存管理和本地缓存，实现了更高的内存效率。

网络带宽消耗

网络方面，差异更是明显：

网络指标	OceanBase	金仓	差异原因
节点间流量	高峰8.2Gbps	<1Gbps	OceanBase副本同步，金仓仅集群心跳
客户端流量	3.1Gbps	2.8Gbps	差异不大
总网络流量	11.3Gbps	3.8Gbps	金仓网络开销低很多

OceanBase的分布式架构决定了它必须依赖高速网络来同步数据，而金仓的共享存储架构节点间通信量极低。这意味着在相同的网络环境下，金仓可以支持更多的并发连接。

四、运维成本：总拥有成本（TCO）的考量

性能和资源之外，运维成本是很多企业忽视但实际上非常重要的因素。我们算了一笔账：

人力成本

运维任务	OceanBase需要人天/年	金仓需要人天/年	说明
日常巡检	120	45	OceanBase组件多，巡检复杂
故障处理	35	12	OceanBase分布式故障定位难
性能调优	25	15	OceanBase分布式调优复杂
版本升级	15	5	OceanBase升级影响大，金仓平滑
备份恢复	30	20	OceanBase备份策略复杂
总计	225人天/年	97人天/年	金仓运维成本低57%

按一个DBA年薪30万算，金仓每年能省下约10万的运维人力成本。这还不算因为故障停机带来的业务损失。

硬件成本

在硬件方面，我们做过一个对比配置：

硬件组件	OceanBase方案	金仓方案	成本差异
服务器	3台高性能服务器	2台高性能服务器 + 共享存储	金仓方案贵15%（共享存储）
网络设备	需要25Gbps网络	千兆网络即可	金仓网络成本低80%
存储容量	3副本，3倍容量	1份共享存储	金仓存储成本低66%
总硬件成本	100万	85万	金仓方案低15%

虽然共享存储本身成本较高，但考虑到OceanBase需要3副本存储和高速网络，总体上金仓方案在硬件上还是更经济。

培训成本

OceanBase的分布式思维与传统关系型数据库差异巨大。我们的团队从传统数据库转到OceanBase，适应了差不多3个月。而转到金仓，因为语法和概念都很熟悉，一周就上手了。

这个学习成本虽然不直接体现在账面上，但实际上影响了项目的交付速度和故障响应时间。

五、实战案例：一个转账系统从OceanBase迁移到金仓

理论说多了有点空，我讲个实际案例。去年我们把一个核心转账系统从OceanBase迁移到了金仓。

迁移动机

这个系统是行内核心交易系统，特点是：

事务量：日均8000万笔
延迟要求：P99延迟不能超过20ms
一致性要求：强一致性，不能出现任何资金风险

在OceanBase上运行时，虽然功能没问题，但P99延迟经常超过25ms，业务部门投诉不断。而且每次做版本升级，都要停机窗口，业务影响很大。

迁移过程

迁移过程比想象中顺利：

评估阶段（1周）：使用金仓的KDMS工具评估兼容性，98%的代码无需修改
同步阶段（2周）：用金仓的KFS工具做数据同步，双轨并行运行
切换阶段（1天）：业务低峰期切换，停机时间<5分钟
优化阶段（2周）：根据金仓特性做了一些索引和参数调优

迁移效果

迁移后，各项指标全面提升：

指标	OceanBase	金仓	提升幅度
P99延迟	25.3ms	11.2ms	↓56%
TPS	8,200	11,500	↑40%
CPU使用率	78%	55%	↓23个百分点
故障恢复时间	分钟级	秒级	显著提升
运维人力	3人	1人	↓67%

最重要的是，迁移后系统运行半年，没有出现过一次因为数据库导致的故障。而在OceanBase上，每月总有一两次小抖动，虽然不致命，但让人提心吊胆。

总结

在这结个尾，博主想说的其实很简单：OceanBase和金仓代表的是两种不同的架构哲学，没有绝对的好坏，只有适合与不适合。如果你做的是互联网应用，需要应对爆发式增长和海量并发，OceanBase的分布式架构可能是更好的选择。但如果你做的是金融、电信、政务这类核心系统，对延迟、一致性、复杂查询有极高要求，那么金仓这种经过多年打磨的集中式/共享存储数据库，这个是博主很推荐的。

技术选型最怕的就是拿着锤子找钉子。分布式不是万能药，传统架构也不是老古董。关键是回归业务本质，看你的业务到底需要什么样的特性。