最近和券商同行朋友聊起他最近的工作，他们公司正在筹备两地三中心的国产信创替换，目前还处于数据库选型阶段，尚未对接厂商，而选型的重点也集中在架构适配、业务切换、容灾保障这三大核心维度。
他初步选定了一款分布式数据库，据行业内同行反馈，实际使用体验都很不错。我们俩详细讨论完初步方案后，我突然问了他一个关键问题：这个方案的成本，公司能覆盖吗？
他猛地打了个激灵：对哦，今年存储成本水涨船高，不光是存储，内存及其他硬件成本也在持续攀升。在我们过去的项目经验里，往往没有把硬件成本核算得过于精细，但这事到了2026年，已经不得不重点考量了。于是，我们围绕成本控制，对原方案展开了更深入的探讨。
原方案解析
首先，金融行业两地三中心是经典容灾架构，他们规划的三个数据中心分布如下：
-
IDC1：上交所托管机房，成本最高，但对证券交易而言是最优选择——无论是极速交易的低延时需求，还是行情资讯的实时获取，都比自建机房更有优势。
-
IDC2：上海同城机房，作为同城灾备节点，成本相对托管机房更低，适合部署对行情资讯和交易响应实时性要求不高的业务。
-
IDC3：北京异地机房，纯粹作为异地灾备节点，大部分时间处于闲置状态，因此资源分配相对较少。
他们的核心业务场景主要分为四类，各有明确的性能需求：
-
极速交易：面向机构客户的核心业务系统，对低延时、高并发要求极高，只能部署在托管机房（IDC1）。
-
主柜台：核心交易支撑系统，考虑到其业务关键性，以及与其他交易系统的高频交互需求，同样只能部署在托管机房（IDC1）。
-
财务系统：以日终结算为核心场景，对实时性要求不严格，可部署在同城机房（IDC2）。
-
风控合规系统：基于市场行情、业务指标、财务数据运行风控模型，开展反洗钱、异常交易监管等工作，对实时性要求相对较低。
按照原规划，IDC1作为两个交易系统（极速交易、主柜台）的生产节点，IDC2、IDC3作为其灾备节点；两个非交易系统（财务、风控）以IDC2为生产节点，IDC1、IDC3作为其灾备节点，尽可能最大化利用机房资源。
数据分片方面，四个业务系统各自独立分片，优先将资源倾斜给交易系统；多副本配置上，所有业务数据均要求保留5副本，其中生产机房部署3副本，灾备机房各部署1副本。具体分片与机房的对应关系如下：
-
分片1：极速交易系统
-
分片2：主柜台系统
-
分片3：风控合规系统
-
分片4：财务系统
-
IDC1：分片1、分片2各部署3副本，分片3、分片4各保留1副本；
-
IDC2：分片3、分片4各部署3副本，分片1、分片2各保留1副本；
-
IDC3：所有分片均部署1副本。
结合原方案的架构规划，我们核算了所需的硬件资源：
按照5副本、4分片的配置，理论上需要20个存储节点；每个业务系统至少需要4个计算节点。管理节点和事务节点方面，生产机房（IDC1、IDC2）均需部署至少2个（避免单点故障），灾备机房（IDC3）可按最小化配置，盘中业务和盘后共享部署在1个计算节点（极速交易+财务管理1节点，主柜台+风控合规1节点）。具体分配如下：
核算下来，仅服务器就需要16+16+8=40台，这还未包含4分片、5副本对应的存储硬件成本。这个数量让他瞬间心态有点崩，这已经是最小化部署的配置，实际生产中所需的硬件资源只会更多。于是我们开始复盘，究竟哪里可以实现成本管控。而肉眼一看可见的就是，节点类型太多了。
首先聚焦存算分离与存算一体两种架构的选型，两种架构各有优劣，没有绝对的好坏，核心是匹配业务场景。
-
存算分离：优势是延时低、资源隔离性好，计算节点宕机不会导致数据丢失；缺点是硬件成本更高，且对OLAP（分析型）业务的适配性有待提升。
-
存算一体：优势是硬件成本更低，且能较好适配OLTP（交易型）和OLAP（分析型）两类业务；缺点是资源隔离性不如存算分离，可能出现性能抖动。
结合四个业务场景的特性：分片1（极速交易）、分片2（主柜台）是典型的OLTP业务，分片3（财务系统）属于HTAP业务，分片4（风控合规）是典型的OLAP业务。从业务适配性来看，存算一体架构能兼顾更多业务类型，同时显著降低成本。反观原方案，选用存算分离架构部署所有4类业务，其合理性值得商榷，而由此增加的服务器成本，更是让人难以承受。
过往数据库选型中，硬件成本往往不会抠得过于精细，因为整体硬件价格相对可控；但从去年开始，内存价格暴涨，今年服务器整机价格更是大幅攀升，极端情况下整体硬件成本甚至上涨200%，这种背景下，成本管控必须提上日程。
除此之外，原方案还有一个隐形支出：分库分表架构在数据量较小时无明显问题，但一旦数据量增长到临界点，就需要额外构建一套后置汇聚业务数据库，这又会增加一笔硬件和运维成本。
这也让我们意识到：如今数据库选型与硬件成本已经高度绑定。过往选型优先考虑业务适配，而现在，除了满足业务需求，必须将硬件成本纳入核心考量，成本过高的方案即便业务适配，也不具备落地可行性。
正如我多年来一直强调的观点：无论作为架构师还是DBA，永远要有成本思维。既然我们不能直接为公司创造收益，就更要思考如何通过合理规划，为公司节省成本。
需求重构
既然原方案的存算分离架构成本过高，我们便将方向锁定为存算一体数据库。结合券商的业务特性和信创要求，我和他共同梳理出6点核心需求，缺一不可：
-
符合金融监管要求，支持两地三中心架构及主备无缝切换，可跨地域、跨机房实现数据实时同步；
-
支持多副本和数据分片，既能保证数据冗余、满足容灾需求，又能实现业务数据的物理隔离；
-
同时支持OLTP和OLAP业务，最好能兼容MySQL和Oracle两种语法语义，降低应用迁移成本；
-
资源利用率最大化，兼顾计算资源与存储资源的高效利用，避免浪费；
-
组件尽量精简，减少硬件资源占用——多一种组件，就意味着多一笔硬件和运维成本；
-
完全符合国产信创要求，适配券商信创替换的政策导向。
用OceanBase爆改后的方案
成本核算和需求梳理完成后，我直接拿出了之前做过的券商合规系统改造方案，建议他用OceanBase重新规划——这款数据库恰好能满足所有核心需求，且能最大化控制成本。
-
分布式架构：支持将不同Zone映射到不同物理机房，天然适配两地三中心架构，满足监管要求和信创需求（对应需求1、6）；
-
多副本与分片：四个业务系统仍沿用“托管机房做交易主节点、同城机房做交易备节点+非交易主节点”的思路，通过多副本机制实现数据在不同Zone（机房）的分布，同时满足数据冗余和物理隔离需求（对应需求2）；
-
资源隔离：通过多租户和主副本调度特性，将每个业务系统的主副本部署在独立物理服务器，备副本部署在其他服务器，实现逻辑与物理双重隔离（对应需求2）；
-
精简架构：组件高度精简，无需额外部署存储、计算分离组件，同时完美适配OLTP、OLAP、HTAP三类业务，兼容MySQL和Oracle语法（对应需求3、5）；
-
资源利用率：这一点，我们在完整方案规划完成后，再详细说明。
我们开始规划整个方案
- 机房与Zone对应规划
-
IDC1（上交所托管机房）： Zone1，主打交易业务，依托托管机房低延时优势，部署极速交易、主柜台系统的主副本；同时作为风控合规、财务系统的同城灾备节点。
-
IDC2（上海同城机房）： Zone2，主打盘后业务，通过OceanBase多副本机制，将Zone1的交易系统数据同步至Zone2，作为风控合规、财务系统的主副本部署节点。
-
IDC3（北京异地机房）： Zone3，作为所有业务系统的异地灾备节点，按最小化原则分配资源，无特殊需求不做扩展。
- 租户规划
-
系统租户（sys租户）：用于管理整个OceanBase集群，以Zone1为Primary Zone，在Zone1部署3个全功能副本，在Zone2、Zone3各部署1个只读副本。
-
租户1（主柜台系统）：采用Oracle兼容模式，使用全行存，以Zone1为Primary Zone，在Zone1部署3个全功能副本，在Zone2、Zone3各部署1个只读副本。
-
租户2（极速交易系统）：采用MySQL兼容模式，使用全行存，以Zone1为Primary Zone，在Zone1部署3个全功能副本，在Zone2、Zone3各部署1个只读副本。
-
租户3（风控合规系统）：采用Oracle兼容模式，结合行存+列存（适配OLAP场景），以Zone2为Primary Zone，在Zone2部署3个全功能副本，在Zone1、Zone3各部署1个只读副本。
-
租户4（财务系统）：采用Oracle兼容模式，结合行存+列存（适配HTAP场景），以Zone2为Primary Zone，在Zone2部署3个全功能副本，在Zone1、Zone3各部署1个只读。
- 资源分配
结合物理资源与逻辑资源完全隔离的需求，最终服务器副本分配如下，而资源分配上，我们将每个副本部署在不同的OBserver上确保物理资源的隔离：
通过多租户机制实现逻辑隔离，每个副本独立部署在一个observer节点上，彻底实现物理隔离。
- 资源利用率优化
为了进一步提升计算资源利用率，我们还可以优化Leader副本的负载均衡。例如Zone1中observer5、observer6作为主柜台租户的Follower副本，闲置计算资源可进一步利用。通过开启enable_ls_leader_balance参数，采用日志流负载均衡模式，可将部分业务的Leader副本调度到observer5、observer6上，充分释放这两个节点的计算潜力，实现资源利用最大化。
最后的架构图如上。一共25个节点。
第二笔经济账
- 服务器成本直接缩减
直观对比来看，原方案需要40台服务器，而OceanBase优化方案仅需25台，直接减少15台服务器的采购成本——相较于原存算分离方案，服务器资源减少了60%。这不仅是一次性的采购成本节省，后续的服务器维保、机房电费、运维人力成本也会随之大幅降低，长期来看，成本优势会更加明显。
- 存储资源进一步压缩
除了服务器数量减少，OceanBase的内置多级压缩机制，还能进一步降低存储成本。券商业务系统的核心数据以文本、数字为主（非结构化数据如文档、图片不会直接存储在数据库中），而OceanBase针对这类数据优化了压缩策略：结合列式存储、字典编码、行程编码等技术，叠加ZSTD或LZ4压缩算法，平均压缩比可达4:1以上。
这意味着，原本需要10T的存储资源，经过压缩后仅需2.5T左右即可满足需求——尤其是主柜台、极速交易这类数据量巨大、对存储性能要求高的系统，存储成本的节省效果会更加显著。
- 计算资源动态调度，利用率最大化
第一版方案中，我们采用各业务系统独享计算资源的方式，保障业务隔离；但进一步分析后发现，交易系统与盘后系统的业务高峰时段存在错峰：交易时段（9:30-15:00），极速交易、主柜台系统负载最高，而风控、财务系统负载较低；盘后时段（15:00后），财务系统日终结算、风控系统模型运算进入高峰，交易系统则处于低负载状态。
基于这种错峰特性，我们可以通过OceanBase的动态资源调度功能，进一步优化资源利用率：交易时段，将系统租户、风控合规、财务系统的闲置计算资源，动态划拨给极速交易、主柜台系统；盘后时段，再将交易系统的闲置资源，划拨给财务、风控系统。通过这种动态调度，25台服务器的计算资源可实现错峰复用，利用率相较于原方案翻倍，无需额外增加硬件，即可满足所有业务的性能需求。
合规与安全
对于券商以及其他金融机构而言，信创替换不仅要控成本保性能，更要守住合规安全的底线。这也是我认为OceanBase能成为最优解的核心底气之一。结合证券业务的监管要求和信创诉求，以及目前OceanBase的发展现状，优势主要体现在三个方面，完美契合金融行业的核心红线需求：
合规适配，深度贴合金融监管，满足券商全场景合规要求。OceanBase的合规能力经过了国内头部券商、银行的大规模实践验证，符合证券行业的监管规范，无需额外投入成本适配改造。另一方面，其天然支持两地三中心和多副本容灾架构，能够实现RPO=0、RTO<30秒的灾备标准，满足监管对容灾备份和业务连续性的硬性要求。完美适配券商极速交易、日终结算的高可用需求。而另一方面，OceanBase内置了完善的合规审计体系，支持操作日志、交易日志、数据变更日志的全量留存，日志留存时长可按需配置且不可篡改，可直接对接券商风控合规系统，满足反洗钱、异常交易这些高标准严要求的监管。数据访问权限可根据券商业务敏感程度，设置访问权限，符合金融数据隐私保护相关法规。
安全保障，全链路防护，守住券商核心数据安全底线。券商核心数据，例如客户信息、交易记录、资金流水，在内部都属于高敏感级别，数据的安全性至关重要。基于多租户架构，实现的不同业务系统的权限隔离，杜绝越权访问。OceanBase在数据传输层面，支持SSL/TLS加密传输，确保交易数据、客户信息在跨机房、跨节点传输过程中不被窃取、篡改；数据存储层面，除了多级压缩机制，还支持数据加密存储，满足金融数据加密存储的监管要求，同时支持数据备份加密，进一步保障灾备数据安全。这些看起来不被大家过多关注的特性，却在金融行业有着举足轻重的地位，没有哪个CTO或者CIO能够忽略。
信创适配，作为国产分布式数据库的标杆，OceanBase完全基于自主研发，核心代码自主可控，能够规避信创替换中的技术卡脖子风险，符合券商信创替换的核心导向。当然，适配还分硬件和软件。在硬件适配层面，OceanBase兼容华为鲲鹏、飞腾、海光这些国产CPU，以及国产服务器、国产存储设备，不需要对硬件进行额外改造，就能直接对接券商现有信创硬件环境，降低硬件替换成本。在软件生态适配层面，兼容麒麟、统信等国产操作系统，针对券商现有业务系统多基于MySQL、Oracle开发的现状，也能够做到大幅降低应用迁移成本，不需要对原有业务代码进行大规模修改，减少信创替换对业务的影响。后期验收能够减少很多不必要的工作量。
每个行业都有自己的安全红线，任何数据库产品都必须做到才能走进客户的核心业务。
最后的总结，既要又要还要
券商两地三中心的国产信创替换，从来不是选一款能满足业务的数据库那么简单。尤其在硬件成本持续暴涨的2026年，选型的核心已经从单纯适配业务升级为合规、性能、成本三者兼顾。
复盘整个过程，朋友原方案的核心问题的在于，沿用了过往重业务轻成本的选型思路，选择存算分离架构部署所有业务，导致硬件资源冗余、成本失控，40台服务器的配置既超出预算，也造成了资源浪费。
而我给他的OceanBase方案的核心优势，在于精准贴合券商的业务特性与成本诉求。以存算一体架构为基础，既满足了两地三中心的监管要求、多业务场景的性能需求，又通过多租户隔离、资源动态调度、多级数据压缩等特性，将服务器数量缩减至25台，大幅降低采购维保运维等全生命周期成本；同时，其兼容MySQL、Oracle双语法，精简的组件设计，也降低了应用迁移和日常运维的难度，完美适配券商信创替换的核心需求。
这也再次印证了我一直强调的观点，作为架构师或DBA，我们的核心价值不仅是保障业务稳定运行，更要具备成本思维。在不牺牲合规性和业务性能的前提下，通过合理的架构规划、精准的数据库选型，为公司节省每一笔不必要的开支。对于券商等金融机构而言，信创替换不是完成任务，而是提质增效降本减耗的契机，选择一款既能扛住核心业务压力，又能实现成本可控的数据库，才是信创落地的最优解。
硬件会涨价，供应链会波动，但领先技术带来的架构优化价值永不贬值。