这两天一直在研究这个话题，踩了几个坑，把遇到的东西整理成文，供有需要的朋友参考。

前言

上周帮一个朋友单位把关信创选型，OceanBase 跟金仓二选一。两边都来了人，PPT 厚厚一沓，会开了一下午，没吵出结果。

推 OB 的说，人家银行核心都跑过了，分布式多牛。推金仓的说，我们在政企市场干了二十多年，图的就是稳。

回来的路上我一直在琢磨，两边吵的说实话全是名词。什么 Paxos，什么共享存储，听着热闹，落不了地。真到落地，纠结的就两件事：延迟差多少？复杂 SQL 谁接得住？

这两块我刚好都踩过坑，写出来给后面的人参考。丑话说在前面，多少带点个人倾向，但不忽悠人。

一、先看骨架

OceanBase（下面简称 OB）是原生分布式。表进去先切分区，分区往一堆服务器上撒，每个分区默认存三份，副本之间靠 Paxos 投票选主、同步日志。没有中心节点这一说，坏一台，多数派里挑个副本顶上，服务接着跑。

金仓（KES）走集中式。一个实例把数据全管了，缓冲区、锁、事务、优化器，全在一个进程里转。要高可用就上主备，备库拉日志追主库。要求再高点，上共享存储集群，好几个实例读写同一份数据，一台倒了另一台秒级接管。数据从头到尾就一份。

对比项OceanBase金仓数据库 KES架构形态原生分布式，分区打散多机集中式单实例，集群另配数据副本每分区默认三副本，数据存三份主备各一份；共享存储集群全局一份写事务提交Paxos 多数派确认，跨分区加两阶段提交本地日志刷盘即返回高可用副本自动选主，RPO=0主备切换或共享存储多活接管扩展方式加服务器即水平扩容纵向升配为主，集群分担读压力

路线本身分不出高低，合不合适的事。但骨架差这么多，后面延迟和 SQL 的账，算法就完全是两码事了。

二、延迟：一条 COMMIT 要走多少路

拿条最普通的转账来看：

BEGIN;
UPDATE account SET balance = balance - 100 WHERE acct_no = '622200001';
UPDATE account SET balance = balance + 100 WHERE acct_no = '622200002';
COMMIT;

先看金仓。COMMIT 一到，两条变更日志（WAL）写本地盘，刷盘，回客户端一句"好了"。没有网络什么事。SSD 上这一步一般 1ms 都不到。

就这么点事。

主备要是配了同步复制呢？多等备库一跳，也就一跳。而且异步、同步、极致安全几个档随便挑，想拿多少延迟换多少安全，自己定。

换到 OB 上，同样的 COMMIT 就绕了。两条 UPDATE 各落在分区的 leader 上，日志要发给同分区另外两份副本，多数派（三份里的两份）确认落盘，事务才算提交。这一跳跨服务器，多数时候还跨机房。要是事务碰巧跨了分区（上面那例子俩账号的分区八成不在一起，太常见了），还得走两阶段提交，协调、准备、提交，网络又跑两趟。

肯定有人不服：同城机房往返也就零点几毫秒，单笔还是毫秒级，无感。

行，这话没错，OB 在银行核心跑得动是真的。但一笔业务逻辑往往是几十条短事务串出来的。每条差零点几毫秒，乘上事务数，乘上并发，高峰期一拉开就不是小数了。对账、清结算这种延迟敏感的活儿，这笔账建议真拿计算器按一按。

那到底差多少？看机房，看分区设计，看业务模型，没有通用数字。谁跟各位拍胸脯报一个固定数，各位反倒要留个心眼。

三、复杂 SQL

延迟是事务型的账。报表的账，得看 SQL 执行器。

我摆一条典型报表 SQL，三表关联、嵌套子查询、窗口函数全有：

```
-- 各区域近30天的客户消费榜：谁贡献了头部销售额
SELECT
FROM (
SELECT r.region_name,
c.cust_name,
SUM(o.amount) AS total_amt,
ROW_NUMBER() OVER (PARTITION BY r.region_name
ORDER BY SUM(o.amount) DESC) AS rn
FROM orders o
JOIN customer c ON o.cust_id = c.cust_id
JOIN region r ON c.region_id = r.region_id
WHERE o.pay_time >= CURRENT_DATE - INTERVAL '30 day'
AND o.amount > (
SELECT AVG(amount) 0.1 -- 滤掉零头小额订单
FROM orders
)
GROUP BY r.region_name, c.cust_name
) t
WHERE rn