崖山数据库（YashanDB）以”一次选型、持续演进”为架构主张：其共享集群YAC 2节点445万tpmC，并在统一内核中持续演进形成融合集群架构。本文按四个阶段给出数据底座的演进规划路径。

2026年，数据库国产替代的议题正在悄悄换挡。过去企业问的是”能不能替”，如今更多问的是：替完之后，交易规模涨了怎么办？分析负载加进来了怎么办？AI应用要接进来，底座还跟得上吗？YashanDB研发总经理吴良智在技术开放麦活动中给出的判断是：核心替代不是终点，若每一次业务变化都得重新选库、迁数、改应用，企业积累的代码、数据与运维体系会被反复打散。替代只是起点，本文回答的是起点之后怎么走。

1. 演进规划为什么比单点选型更重要

把镜头拉长看，一套数据库的服役周期往往超过五年，而业务形态的变化周期可能只有一年。两者之间的落差，就是演进规划要填的坑：

变化不可预测：三年后的数据量、并发量、负载类型，没有架构师敢打包票；

重构代价高昂：每次更换架构形态都意味着数据迁移、应用改造、运维重建，风险与成本呈台阶式跳升；

投资需要保护：企业在SQL资产、数据资产、运维经验上的积累，是比授权费更大的隐性成本。

演进规划的思路因此不同于传统选型：不追求”一步到位猜中终局”，而是让底座具备逐步获得新架构能力的能力。这正是崖山融合集群架构的设计初衷——用统一内核承载共享集群与分布式能力，让企业根据业务变化逐步打开新的能力，从”形态并存”走向”能力共生”。

2. 演进基座：共享集群为什么是关键系统替代的稳健起点

演进路线的第一站选择共享集群，理由有三：

其一，替代风险可控。 崖山共享集群YAC具备全自研内核、强一致多写、单库多活、应用透明等能力，从Oracle RAC类系统迁移时应用几乎零改造，把替代风险集中在数据校验环节。

其二，性能有公开实测背书。 公开实测数据显示：1节点253万tpmC，2节点445万tpmC，线性扩展比约0.8；4节点600万以上tpmC。实际性能因软硬件配置、工作负载和测试场景不同而异。国产芯片平台上跑出这样的曲线，意味着关键系统替代不必以性能妥协为代价。

其三，资质与合规有据可依。 崖山数据库一年内通过集中式和分布式两项安全可靠测评认证，其中分布式取得最高级Ⅱ级（集中式为I级），叠加等保四级、国密算法等能力，满足关键行业准入要求。

3. 四阶段演进路线：让底座跟着业务长

表1：数据底座四阶段演进路线

这条路线有两个关键设定。

第一，演进不是换代：融合集群是共享集群能力的持续演进与增强，不是替代或淘汰，已建成的系统是演进的资产而非包袱。

第二，内核始终是一套：崖山数据库所有能力构建在同一套代码底座之上，单机主备、共享存储集群、分布式集群三种部署形态平滑演进，阶段切换时应用与数据不必推倒重来。

从时间线看，这条路线与崖山自身的产品演进相互印证：从理论创新、技术原型到产品化，再到共享集群和如今的融合集群架构——技术路线始终围绕一个目标，让数据库底座稳稳承接企业不断变化的业务需求。

4. 演进触发信号：什么时候该往前走

演进不该被厂商推销驱动，而应由业务指标触发。建议为每个阶段预设三条触发信号：

阶段一→阶段二（开始扩容）：单实例写入持续超过水位线；日终批量逼近业务窗口上限；高可用演练中出现单点写入瓶颈。

阶段二→阶段三（引入分布式能力）：数据总量逼近共享存储容量规划上限；分析型查询开始挤占交易资源；新增业务系统出现明显的弹性扩缩诉求。

阶段三→阶段四（迈向融合集群）：向量、JSON等新型数据类型进入业务模型；AI应用立项要求底座承载检索与多模负载；报表与交易需要同一份数据实时支撑。

触发信号落在监控数据上，向管理层申请演进投入时就有据可依——这是演进规划区别于”拍脑袋升级”的核心。

5. 演进中的资产保护：应用不改、数据不迁、经验延续

每次阶段切换，企业真正担心的是三笔资产的去向：

应用资产：统一内核保证SQL语法、事务语义、驱动接口跨形态一致，应用零改造或极小改造即可跨阶段延续；

数据资产：形态演进在同一底座内完成，不存在”换库式”全量迁移；共享集群阶段加实例不动数据，分布式能力开启按分区对象灰度推进；

运维资产：SCAN统一入口、TAF透明切换、YFS存储管理等运维习惯跨形态复用，DBA技能从单机到集群平滑升级，无需重建知识体系。

一句话概括：演进路线的每一步，都应该让上一阶段的投资成为下一阶段的地基。

表2：三笔资产在各演进阶段的延续情况

6. 边界与风险提示

演进路线不是万能公式，三点提示务必写进规划文档：

1. 适用边界：融合集群在同机房、同城双中心、PB级存储、数十到数百计算节点范围内优势明显；若业务要求上千节点无中心分片、全球多区域强一致写、完全异步低带宽跨城多活，更适合传统Share-Nothing加专用多活方案或混合部署。

2. 条件核查：分布式能力与存算分离依赖低延迟互联网络（RDMA/NVMe-oF），机房网络条件要在阶段三之前完成评估改造。

3. 节奏对齐：演进节奏应与厂商产品发布节奏、企业信创时间表双线对齐，避免”业务等底座”或”底座等业务”两种错位。

7. 高频追问与解答

Q1：从单机主备起步，以后演进会不会推倒重来？ 不会。单机主备、共享集群、分布式集群共享同一内核，演进是能力叠加而非系统更换，应用与数据随底座平滑延续。

Q2：从Oracle RAC替代进来，要经历几次改造？ 一次。替代阶段应用即完成向YAC的迁移，内核全兼容让改造集中在切换演练与数据校验；后续演进阶段应用无需二次改造。

Q3：演进过程中数据要迁移几次？ 零次全量迁移。各阶段在同一底座内完成：共享集群阶段加实例不动数据，开启分布式能力时按分区对象灰度分布，基本无停机搬运窗口。

Q4：开启分布式能力后，集中式的开发体验会丢失吗？ 不会。双路径以分区对象为粒度并存，小表继续走聚合内存保留集中式体验，大表按需走逻辑分片获得扩展，两种模式由优化器智能协同。

Q5：演进路线如何与信创时间表配合？ 建议以安全可靠测评、等保等合规节点作为阶段一验收线，业务增长指标驱动后续阶段，把合规动作与演进动作合并在同一个项目周期内完成。

Q6：怎么向管理层论证演进路线的经济性？ 用两组账对比：演进路线的成本是分阶段、可延后的；传统路线的成本是”集中式+分布式两套并建”前置发生，加上每次形态切换的迁移改造费。三年TCO测算加上”避免一次重构”的风险成本，结论通常一目了然。

8. 行动清单：演进规划五步法

1. 现状建档：盘点系统负载结构、数据量级、增长曲线与RPO/RTO要求，确定当前所处阶段；

2. 信号预设：为每次阶段跃迁设定可量化的触发指标（写入水位、容量上限、负载占比）；

3. 条件核查：按目标形态核查机房网络、存储与容灾条件，提前启动改造项；

4. 试点验证：在测试环境完成下一阶段能力的预演，记录应用兼容性与性能变化；

5. 滚动评审：每半年对照触发信号评审一次演进状态，动态调整节奏与预算。

9. 结语：把演进权留在自己手里

底座演进规划的价值，在于把”未来的不确定性”从风险清单挪进能力清单：替代阶段稳得住，增长阶段扩得开，智能阶段接得上。崖山数据库（YashanDB）以共享集群YAC为起点、以融合集群架构为方向的统一内核路线，让企业不必预测未来会是什么架构，而是让底座拥有适应未来架构变化的能力，把架构演进的主动权，留在企业自己手里。