聊聊国产数据库选型：KingbaseES和OceanBase在性能和成本上的那些事儿

聊聊国产数据库选型：KingbaseES和OceanBase在性能和成本上的那些事儿

其实咱们前面花了不少时间，聊了数据怎么搬、怎么做评估这些个前置工作。也就是说，咱们用KDMS评估完了，也用KFS把数据平滑同步过来了。那么接下来呢？数据到了新库里，真正开始跑业务了，这时候数据库本身的性能竞争力，就成了咱们最关心的事儿了。

现在市面上国产数据库特别多，乱花渐欲迷人眼。很多兄弟在选型的时候，看这个也好看那个也好。其实咱们干一线的，不看你PPT写得多漂亮，就看你在我这机器上，跑得快不快，吃资源多不多，半夜出事了好不好查。今天咱们就拿金仓的KingbaseES和OceanBase来做个对比。咱们从架构效率、场景优化、资源消耗，还有运维成本这几个维度，掰开揉碎了唠唠。看看这俩玩意儿到底在延迟和复杂SQL执行上，有啥根本差异。

一、 架构效率：分布式和集中式，到底谁 latency 更低

咱们先说架构。这俩库，底子是完全不一样的。OceanBase走的是分布式路线，基于Paxos协议。金仓KingbaseES呢，走的是传统集中式，或者说共享存储架构。这俩架构碰在一起，在延迟上，也就是latency，那差别是真的大。

1.1 OceanBase的Paxos协议，投票得花时间啊

咱们先看看OceanBase这套分布式咋回事。它用Paxos协议。Paxos这玩意儿，说白了，就是一群人投票。你要写一条数据，不能你一个人说了算。你得跟另外两个兄弟说一声。兄弟说行，这事儿才算定。这就是所谓的多数派同意。

那这个过程是啥样的呢？你发个写请求过来。OceanBase的Coordinator节点接到了。它把这个请求发给各个副本。接着，各个副本要在内存里记下来。然后给Coordinator回话。Coordinator收到多数派（通常是三个里面的两个）的回复了。它才敢跟客户端说，写成功了。你看，这中间有多少次网络交互？这都是在同一个机房里头，那也得花时间啊。通常来说，光这个Paxos的确认，就得消耗好几毫秒。这还是顺利的情况。要是碰到哪台机器网卡抖了一下，或者负载高点，那延迟直接就上去了。

这是一个根本性的问题。分布式架构为了保证高可用和数据不丢，它必须这么干。那这就意味着，它的写延迟，在物理上就被多加了几道关卡。你业务层是没法绕过去的。

1.2 金仓KingbaseES的集中式，直来直去没弯弯绕

咱们再看看金仓KingbaseES。它是集中式架构。也就是说，它就是老老实实地在一台机器上跑（主备模式另说，主备也是主在干活）。如果你用的是共享存储架构，比如接个SAN存储，那数据文件就在存储上。计算节点就一个。

这玩意儿处理写请求，那就简单多了。你发个写请求过来。数据库引擎接到。直接在本地内存里改。改完写个WAL日志。这WAL日志往本地磁盘一刷。行了，告诉客户端，成功了。它不需要去问别人。不需要在网络上跑来跑去问兄弟们同不同意。

那么它的延迟是多少呢？通常来说，如果你开了同步提交，也就一毫秒以内。要是你能忍受一点点丢数据的风险，开个异步，那基本就是微秒级别的。这种直来直去的架构，在单节点的写延迟上，天然就比分布式有优势。也就是说，如果你的业务是对延迟极其敏感的，比如金融的核心交易，那一秒钟几十万次，每次差那一两毫秒，累积起来就是巨大的差距。

#mermaid-svg-p2dzctUvKlJyXQuV{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-p2dzctUvKlJyXQuV .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-p2dzctUvKlJyXQuV .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-p2dzctUvKlJyXQuV .error-icon{fill:#552222;}#mermaid-svg-p2dzctUvKlJyXQuV .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-p2dzctUvKlJyXQuV .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-p2dzctUvKlJyXQuV .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-p2dzctUvKlJyXQuV .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-p2dzctUvKlJyXQuV .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-p2dzctUvKlJyXQuV .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-p2dzctUvKlJyXQuV .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-p2dzctUvKlJyXQuV .marker{fill:#333333;stroke:#333333;}#mermaid-svg-p2dzctUvKlJyXQuV .marker.cross{stroke:#333333;}#mermaid-svg-p2dzctUvKlJyXQuV svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-p2dzctUvKlJyXQuV p{margin:0;}#mermaid-svg-p2dzctUvKlJyXQuV .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-p2dzctUvKlJyXQuV .cluster-label text{fill:#333;}#mermaid-svg-p2dzctUvKlJyXQuV .cluster-label span{color:#333;}#mermaid-svg-p2dzctUvKlJyXQuV .cluster-label span p{background-color:transparent;}#mermaid-svg-p2dzctUvKlJyXQuV .label text,#mermaid-svg-p2dzctUvKlJyXQuV span{fill:#333;color:#333;}#mermaid-svg-p2dzctUvKlJyXQuV .node rect,#mermaid-svg-p2dzctUvKlJyXQuV .node circle,#mermaid-svg-p2dzctUvKlJyXQuV .node ellipse,#mermaid-svg-p2dzctUvKlJyXQuV .node polygon,#mermaid-svg-p2dzctUvKlJyXQuV .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-p2dzctUvKlJyXQuV .rough-node .label text,#mermaid-svg-p2dzctUvKlJyXQuV .node .label text,#mermaid-svg-p2dzctUvKlJyXQuV .image-shape .label,#mermaid-svg-p2dzctUvKlJyXQuV .icon-shape .label{text-anchor:middle;}#mermaid-svg-p2dzctUvKlJyXQuV .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-p2dzctUvKlJyXQuV .rough-node .label,#mermaid-svg-p2dzctUvKlJyXQuV .node .label,#mermaid-svg-p2dzctUvKlJyXQuV .image-shape .label,#mermaid-svg-p2dzctUvKlJyXQuV .icon-shape .label{text-align:center;}#mermaid-svg-p2dzctUvKlJyXQuV .node.clickable{cursor:pointer;}#mermaid-svg-p2dzctUvKlJyXQuV .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-p2dzctUvKlJyXQuV .arrowheadPath{fill:#333333;}#mermaid-svg-p2dzctUvKlJyXQuV .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-p2dzctUvKlJyXQuV .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-p2dzctUvKlJyXQuV .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-p2dzctUvKlJyXQuV .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-p2dzctUvKlJyXQuV .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-p2dzctUvKlJyXQuV .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-p2dzctUvKlJyXQuV .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-p2dzctUvKlJyXQuV .cluster text{fill:#333;}#mermaid-svg-p2dzctUvKlJyXQuV .cluster span{color:#333;}#mermaid-svg-p2dzctUvKlJyXQuV div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-p2dzctUvKlJyXQuV .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-p2dzctUvKlJyXQuV rect.text{fill:none;stroke-width:0;}#mermaid-svg-p2dzctUvKlJyXQuV .icon-shape,#mermaid-svg-p2dzctUvKlJyXQuV .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-p2dzctUvKlJyXQuV .icon-shape p,#mermaid-svg-p2dzctUvKlJyXQuV .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-p2dzctUvKlJyXQuV .icon-shape .label rect,#mermaid-svg-p2dzctUvKlJyXQuV .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-p2dzctUvKlJyXQuV .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-p2dzctUvKlJyXQuV .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-p2dzctUvKlJyXQuV :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

KingbaseES 集中式写流程

本地内存

本地磁盘

客户端写请求

数据库引擎

写WAL日志

OceanBase Paxos写流程

网络1

网络2

网络2

网络3

网络3

网络4

客户端写请求

Coordinator

副本1

副本2

副本3落盘

1.3 共享存储架构，如何兼顾高可用和低延迟

有人可能会说，你集中式要是那台机器挂了咋办？这不就单点故障了吗。其实金仓KingbaseES现在都支持共享存储架构。比如两台计算节点，后面接一个存储阵列。主节点挂了，备节点立马接管。这个接管速度，比分布式重新选主要快得多。因为数据就在那块盘上，谁连上谁就能读。不用像分布式那样，还得去拉日志补数据。

通常来说，在这种架构下，主节点干活的时候，备节点是可以同时读的。这也就是咱们常说的读写分离。这玩意儿处理延迟，那是实打实的低。因为它没有分布式的网络开销。所有的动作都在本地内存和存储网络上完成。这种架构效率，在面对那种极低延迟诉求的场景时，优势就体现出来了。往往仅仅只是网络通信这一项省下来的时间，就足以让业务的吞吐量翻番。

二、 场景优化：复杂SQL执行效率，谁跑得快

聊完了底层架构，咱们往上看一层。业务系统里跑的SQL，可不是简单的select * from table。那是各种多表关联，嵌套子查询，还有窗口函数。这些复杂SQL，在金仓和OceanBase上，执行效率差别可不小。这其实也是咱们在选型的时候，必须要考虑的场景优化能力。

2.1 多表关联，分布式跨节点Join有多头疼

咱们先说多表关联。比如你有三个表。表A、表B、表C。你要把它们Join起来。在金仓这种集中式库里，这事儿相对简单。数据都在本地。优化器算个成本。是用Hash Join，还是Nested Loop，还是Merge Join。选好了，直接在内存里拼就行了。因为数据不需要在网络上跑。

那OceanBase呢？这就有点头疼了。因为它是分布式的。表A可能在一号机器上，表B在二号机器上。你要把A和B Join，这数据就得过网络。网络传输那可是慢的。这叫跨节点Join。

那它会怎么处理呢？它得想招。比如用Broadcast Join。把小表广播到所有节点上，再跟大表本地Join。或者用Partition Wise Join，如果两个表刚好按关联键做了分区，那就在本地Join。但这都依赖于你的表结构设计得特别好，优化器也特别聪明。那如果说，业务SQL是临时写出来的，或者表结构没法那么完美地分区呢？那数据就得在网络上拉过来拉过去。这一下，执行效率就直接掉下来了。咱们在测试的时候，经常看到一个三表关联的SQL，在单机上跑几十毫秒，到了分布式库上，跑个几百毫秒甚至一秒。原因就在这儿。

2.2 嵌套子查询，优化器能不能看懂你的心思

再看看嵌套子查询。这个咱们开发人员特别爱写。一层套一层，看着挺省事。但这玩意儿对数据库优化器的要求特别高。

SELECT * FROM tab1 WHERE id IN (
SELECT tab1_id FROM tab2 WHERE status = 1 AND name IN (
SELECT name FROM tab3 WHERE age > 20
)
)

你看这种SQL。在金仓里，它有一个很成熟的基于代价的优化器（CBO）。这玩意儿是从PostgreSQL那一脉传下来的，又做了很多优化。它能把你这种子查询，自动改写成Join。改写成Join之后，执行路径就多了。它可以根据表的大小，选不同的Join顺序。这样执行效率就上来了。通常来说，它能处理得很漂亮，基本不用你人工去重写SQL。

但OceanBase遇到这种嵌套子查询，有时候就有点犯怵。虽然它也有优化器，但分布式环境下，子查询展开和下推的规则特别复杂。有些时候，它没法把子查询很好地转成Join，只能老老实实地按嵌套的方式去跑。那是啥结果？就是外层查一次，进到内层查一圈。如果内层结果集大点，那就是个灾难。咱们实测的时候遇到过，同样的嵌套SQL，金仓跑完只要零点几秒，OceanBase跑了十几秒还没出结果。这其实就是场景优化能力的差异。也就是说，在某些特定的SQL写法上，传统的集中式优化器反而更稳当。

2.3 窗口函数，排序和分页的杀手锏

最后说说窗口函数。这个东西在报表系统里太常见了。比如ROW_NUMBER() OVER (PARTITION BY … ORDER BY …)这种。要对数据进行分组排序。还要分页。

这种操作，其实对算力要求很高。因为要排序。在金仓里，这种操作主要消耗内存和CPU。它会用Work Mem来放排序的数据。只要内存够大，基本都在内存里排，速度是很快的。因为它只需要在一台机器上排完就行了。没有协调成本。

那OceanBase呢？如果这个分区表的数据刚好都在一个节点上，那还好说。如果数据分布在多个节点上呢？它就得先在每个节点上排一遍。然后再把结果汇总到顶层节点去排。这叫两阶段排序。这个过程不仅有计算开销，还有大量的网络开销。如果数据量特别大，内存放不下，还得落盘。那速度就更慢了。

也就是说，在处理这种需要大量排序和聚合的复杂SQL时，集中式架构因为没有分布式的数据搬迁成本，执行效率往往比分布式要好。这其实也是架构决定的事情。金仓在这块，因为有成熟的执行引擎，对内存的管理也比较精细，所以在跑窗口函数的时候，表现是非常稳的。

三、 资源消耗：吃内存还是吃CPU，机器怎么配

咱们搞运维的，除了关心快不快，还得关心这玩意儿吃多少资源。老板给的预算就那么多。你买个分布式库，动不动就要搞三台机器起步，还得是高配。这成本谁受得了。这节咱们就聊聊资源消耗。

3.1 OceanBase的内存占用，动不动就给你吃光

先说OceanBase。这玩意儿是个内存数据库。它对内存的渴求是特别大的。通常来说，你装个OceanBase，起步就得64G内存，128G是标配。它有一大块内存叫MemTable。就是用来放增删改的数据的。它不写盘，先在内存里攒着。

这就有个问题了。如果你的业务写入特别频繁，这个MemTable会涨得特别快。涨到一定阈值，它就得冻结，然后转储到磁盘上。在这个转储的过程中，会消耗大量的CPU和IO。如果你的内存不够大，它就会频繁地转储。这会导致系统性能剧烈波动。一会儿快，一会儿慢。而且它有很多后台线程，比如合并线程。合并的时候，那是真吃CPU。几台机器的CPU都能给你干到80%以上。

也就是说，OceanBase是用空间换时间，用资源换性能。你想要它跑得稳，就得给它堆硬件。这其实是一笔不小的开销。很多企业层级里的项目，根本没那么多预算去搞那么好的机器。这就很尴尬了。

3.2 金仓KingbaseES的资源管控，省着点用

咱们再看看金仓。金仓是个传统的集中式库。它对资源的利用，是比较克制的。它不是那种把所有数据都塞内存里的玩法。它是用Buffer Pool来缓存数据块。用的时候读进来，不用了就淘汰掉。通常来说，一个16G或者32G内存的机器，跑金仓就跑得很溜了。

它也有排序内存、哈希内存。这些内存是按需分配的。用完就还回去。它不会像OceanBase那样，一启动就把一大块内存给霸占了。也就是说，金仓是和操作系统配合着来用内存的。操作系统的文件系统缓存，也能帮它很大忙。

那CPU呢？金仓的CPU利用率通常比较平缓。除非你跑了特别复杂的SQL，否则它不会突然飙高。这种资源消耗模式，对于咱们普通的企业级应用来说，是非常友好的。你可以把金仓和别的应用混部在一台机器上，只要隔离做得好，基本不打架。但你要是敢把OceanBase和别的应用混部，那估计别的应用得饿死。往往仅仅只是内存这一项，金仓就能帮咱们省下一大笔买机器的钱。

3.3 硬件成本账，老板最关心的钱

咱们算笔账。假设你有个核心业务。数据量500G。如果你用OceanBase，你至少得搞三台机器吧。每台机器128G内存，16核CPU。这配置不低了吧。三台机器的价格，加上网卡，加上交换机，这硬件成本得小几十万。

如果你用金仓呢。其实一台机器就够了。配个32G内存，8核CPU，再加个好点的SSD。几万块钱搞定。如果你想搞高可用，那就两台机器，做个主备。也比三台便宜。而且后面的存储，可以用现有的SAN，不用额外买。

这就是实打实的成本差异。很多时候，咱们选型选不下来，就是因为分布式架构太贵了。金仓这种集中式架构，在满足业务需求的前提下，能把硬件成本压到最低。这也就是它能在很多传统行业，比如政务、金融的非核心系统里，大面积铺开的原因。因为性价比是真的高。

四、 运维成本：日常维护到底折腾不折腾人

最后咱们聊聊运维。这事儿咱们一线人员最有发言权。库选错了，半夜三更被叫起来排错，那滋味可不好受。所以，运维成本，也是性能竞争力的一部分。你跑得再快，如果天天出幺蛾子，那也是白搭。

4.1 分布式运维的复杂度，排错像大海捞针

先说OceanBase。这玩意儿运维起来，门槛是真的高。因为它太复杂了。你一个SQL跑慢了。你去看执行计划。它那个计划是个分布式计划。啥叫分布式计划？就是它告诉你，这个SQL在节点A上干了啥，在节点B上干了啥，然后汇总到节点C又干了啥。你看完一头雾水。你根本不知道是哪一步慢了。

而且，分布式系统里，各个节点之间的时钟同步、网络抖动，都会影响性能。有时候，明明SQL没问题，机器也没问题，就是因为某一刻网络丢了个包，导致延迟飙高。你去查日志，天南海北的日志散在好几台机器上。你得用各种工具把它们汇总起来看。这就要求运维人员得懂分布式系统的调优。这种人在市场上可不好招，招来了工资也高。

另外，它还有很多特有的概念。比如租户、Unit、资源池。你要给它分配资源。分多了浪费，分少了业务卡。这个度特别难拿捏。通常来说，团队里得有个专门搞OceanBase的DBA，天天盯着这玩意儿调参。这就增加了人力成本。

4.2 集中式架构的简单直接，老DBA的舒适区

咱们再看金仓。金仓的运维，对咱们这种老DBA来说，那就是舒适区。它和Oracle、PostgreSQL太像了。你之前会的那套调优方法，啥看等待事件啊，看AWR报告啊，在金仓这里基本都能直接套用。

一个SQL慢了。你看一眼执行计划。是全表扫描了，还是索引建错了。你自己心里就有数了。加个索引，或者改写一下SQL，立马见效。所有的数据都在本地，不存在跨节点的问题。排错特别简单。看个日志，也就是那几个文件，grep一下就出来了。

还有备份恢复。集中式库的备份恢复，那是相当成熟了。物理备份，逻辑备份，各种工具都有。恢复的时候，指哪打哪。但OceanBase的备份恢复，那叫一个麻烦。它要备份好几个节点，恢复的时候还要保证一致性。搞不好就得折腾一天。也就是说，金仓这种架构，极大地降低了运维的门槛。咱们不需要招那种特别贵的专家级DBA，普通的运维人员培训几天就能上手。这其实是隐形的省钱。

4.3 人员培训成本，好不好招人

这也是个现实问题。你上个新数据库，团队得学吧。学OceanBase，那得从头学起。Paxos是啥，两阶段提交是啥。学半天还搞不明白。市面上懂的人也少，遇到问题想找个懂行的人问问都难。

学金仓呢？其实有PostgreSQL底子的，看金仓的文档，跟看小说一样。一两天就能跑起来业务。遇到报错，百度一下（虽然不一定准），但总能找到点线索。因为它的生态是基于传统关系型数据库的，非常庞大。这就意味着，你团队的学习曲线非常平缓。不需要花大量的时间和金钱去搞培训。这也是一种竞争力。能让你的人才快速转动起来。

五、 总结一下咱们到底该选谁

唠了这么多，咱们来总结一下。其实没有哪个数据库是完美的。关键看你的业务场景是啥样的。这也就是咱们说的性能竞争力的落脚点。

5.1 场景决定架构，别为了分布式而分布式

现在有个不好的风气。就是啥业务都想上分布式。觉得分布式高大上。其实很多时候，你的数据量根本没那么大。一天就产生几十个G的数据。你搞个三节点的OceanBase，纯属杀鸡用牛刀。不仅浪费钱，还增加了运维负担。

如果你的业务是那种高并发、极低延迟、重写轻读的场景。比如核心交易系统。那我强烈建议你看看金仓这种集中式架构。它没有分布式的网络开销，写延迟就是低。它对复杂SQL的执行效率就是高。这种场景下，集中式的架构效率优势是压倒性的。

如果你的业务是那种海量数据、很多个节点、要求强一致性的场景。比如大厂的日志分析、海量图片存储。那你再考虑分布式。但这往往仅仅只是少数大厂的需求。大部分咱们做企业层级里的项目的，用不上这么猛的火力。

5.2 金仓的竞争力在哪，其实就在简单实用

金仓KingbaseES的性能竞争力，其实就是四个字：简单实用。它用成熟的集中式架构，保证了极低的单点延迟。它用强大的CBO优化器，搞定了复杂的SQL关联和子查询。它用克制的资源管控，让咱们能用有限的预算跑起业务。它用贴近传统DBA习惯的运维方式，降低了团队的学习和维护成本。

这些点，看着不花哨，但在实际干活的时候，每一项都能帮咱们解决大问题。也就是说，金仓是个干实事的库。它不跟你玩虚的。你给它多少资源，它就给你干多少活。这在咱们这种讲究降本增效的大环境下，是非常重要的。

其实选型这事，就像找对象。外表光鲜亮丽固然好，但最终过日子，还是得看俩人合不合拍，过日子简不简单。对于咱们一线干活的来说，一个架构清晰、好维护、性能稳的库，才是真正的好库。好了，今天就聊到这儿吧，希望能给大家在选型的时候，提供点不一样的思路。下次咱们再聊聊具体怎么在金仓里调优那些慢SQL。