1.2 设计哲学：三对三角

1.2 设计哲学：三对三角

本节摘要：openGauss 的设计主张可以概括为三对相互牵制的三角：性能—可用—安全决定内核怎么造，兼容—创新—自主决定产品怎么走，内核—工具—生态决定社区怎么长。看懂这三组取舍，很多"为什么它和别人不一样"的问题就有了答案。

直接给结论：理念不是口号，是参数表

读完上一节的历史脉络，这一节换个角度——不看它说了什么，看它把什么做成了默认行为。判断一个数据库的设计哲学，最诚实的材料不是发布会材料，而是默认参数、默认行为和出错时的表现。openGauss 的三高主张（高性能、高可用、高安全）落在安装完成即生效的默认配置上：密码复杂度校验默认开启、审计日志默认记录、主备流复制是文档主推的部署形态。这三件事在不少同类产品里要手工开启，在 openGauss 里是出厂状态。交付工程师能从中读出的信息很直接：这个内核是为"监管多、审计严、不允许裸奔"的场景设计的，它的默认值就是它的价值观。

第一对三角：性能、可用、安全的内核取舍

三者不可能同时拉满，openGauss 的解法是分层各自强化、接口处协调。性能侧，它选择了异步提交可配、同步复制可配的弹性策略，并用 MOT 内存引擎为热数据提供另一种极限；可用侧，主备流复制 + 重组包 CM 组件构成基础盘，备机可读把硬件利用率提上来；安全侧，全密态计算、动态数据脱敏、内置审计把"数据不落明文"做成机制而不是纪律。

用一段会话感受安全默认值的严格程度——尝试设置一个弱密码，内核直接拒绝：

-- 以初始用户连接后创建业务用户
CREATE USER app_rw WITH PASSWORD 'Abc@12345';
-- 若改成弱密码，内核会直接拒绝并提示复杂度不足
CREATE USER app_test WITH PASSWORD '123456';
-- ERROR: The password contains at least 8 characters... (复杂度策略校验失败)
-- 查看当前生效的口令复杂度策略
SHOW password_policy;
​

这不是炫技。在等保测评现场，"口令复杂度由数据库内核强制"是一条可以直接勾掉的整改项。同样的思路体现在审计上：默认审计参数开启后，DDL 与关键 DML 会留下不可抵赖的记录，第 6 章会专门展开。

第二对三角：兼容、创新、自主的产品路线

兼容讲的是"从哪迁来不疼"。openGauss 保留了 PostgreSQL 的 SQL 方言底座，同时通过插件补齐 Oracle 风格的 PL/SQL 语法、数据类型与系统视图，让存量 Oracle 工程师的肌肉记忆大体可用；对 MySQL 生态则提供语法兼容与迁移工具链。创新讲的是"往哪走"：MOT 内存引擎、资源池化、AI 自调优这些方向，都是先于传统商业库在开源版本里落地的。自主讲的是"根基在哪"：全链路开源、社区由中国企业和高校共建，这在关键行业替代项目里是硬性加分项。

三者的张力真实存在。最典型的例子是存储过程：为了兼容 Oracle，内核内建了 PL/SQL 引擎，这让迁移成本大降；但存储过程跑在内核里，也给性能诊断增加了复杂度——定位问题时你要同时懂 SQL 和过程语言。我们的一般主张：迁移期尽情用兼容特性降低改造成本，迁移完成后逐步把重逻辑挪回应用层，给未来的扩容与升级留余地。

第三对三角：内核、工具、生态的社区分工

一个数据库能不能交付，取决于内核之外的东西：备份工具、监控视图、迁移校验、驱动适配。openGauss 社区把这三层分开运营：内核 SIG 管主线，工具 SIG 维护数据搬迁、备份恢复、性能自诊断的全家桶，生态 SIG 对接上下游与商业发行版。对交付团队的实际意义是排障路径清晰——内核行为查源码与内核文档，工具报错先看工具自身的日志与版本配套表，两者别混着查。

FAQ：决策者最常追问的三个问题

openGauss 与 GaussDB 是什么关系？

openGauss 是开源社区版本，GaussDB 是华为基于同源技术的商业数据库产品线。可以理解为上游与下游：商业版在开源内核上叠加了企业服务、云化交付与增强特性。选型文档里要写清楚你用的是哪一个，两者的支持渠道完全不同。

"高性能"是不是宣传话术？

有实绩支撑但要看场景。TPCC 类基准测试的成绩来自特定硬件与配置（含 MOT、NUMA 绑核等针对性优化）；你的业务能不能吃到这些红利，取决于负载形态。正确姿势是用自己业务的压缩版回放测试，别迷信通用跑分。

默认开启审计和口令策略，会不会影响性能？

审计有开销，但量级可控，且审计日志的写盘策略可调。实践中的做法是：核心库全量审计 + 独立审计盘，外围库按等保级别裁剪审计项。把"关审计"当优化手段，在受监管行业等于给自己埋雷。

工程实务补充：把取舍翻译成运维成本

设计取舍最终都折算成交付后的运维成本，这笔账交付方案里要提前算给客户。性能侧的成本：MOT 与 NUMA 绑核这类优化吃硬件规划的前置投入，机器不到位则收益打折，所以硬件采购清单要和技术方案同步评审，别让硬件成为性能承诺的违约点。可用侧的成本：主备与 CM 组件多占机器、多占网络，且把"切换演练"变成持续性义务——演练不做，高可用架构只是一张好看的图。安全侧的成本：审计落盘、加密计算、密钥管理各有开销与岗位要求，等保级别的差异会让安全预算差出数倍。把这三笔成本写成方案附录，验收时的争议会少很多。

一个判断设计哲学是否落地的小实验：新装一台实例，什么都不改，直接跑一轮安全基线扫描与默认参数审查。openGauss 的扫描结果会显示口令策略、审计开启、连接限制等项默认达标——这批"出厂即合规"的项目，就是"安全默认值"哲学的具体形状。同类实验在其他数据库上往往得到一页整改单。这个五分钟的实验比任何白皮书都有说服力，推荐写进选型 POC 的固定环节。

FAQ：设计取舍的边界问题

既然默认安全项都开了，还要安全团队做什么？

默认值覆盖的是"不出错"，安全团队负责的是"不被绕过"：账号治理、权限评审、审计告警的值守、密钥的轮换纪律。内核默认值是地板，不是天花板。

兼容层会永远保留吗？

兼容层的存续取决于存量迁移的生命周期。行业共识是把它当桥梁：迁移高峰期全力投入，替代完成后逐步收敛。对应用团队的启示是：新项目别主动使用兼容层方言，用标准 SQL 与过程逻辑的最小公共集，给未来的迁移留退路。

资源池化上线后，现有主备运维经验还适用吗？

部分适用。日志、事务、锁、优化的知识完全平移；拓扑与切换的流程会变——池化后"实例"的边界被重新定义，切换的对象从机器变成算力单元。所以第 5 章的演练方法论不变，演练脚本要按池化形态重写。

一页速览：三对三角的决策卡

把本节内容压成一张决策卡，评审会上可以直接引用。第一行，内核三角：问性能还是问可靠，答案写在配置档位里——检查你们环境的日志刷盘与提交等待参数，就知道这套系统的第一性诉求。第二行，产品三角：问兼容还是问创新，答案写在对象清单里——数一数存量里过程语言的占比与使用的方言特性，占比高说明这套系统活在兼容桥上，桥的存续期要纳入技术债台账。第三行，社区三角：问自主还是问省心，答案写在采购合同里——社区版加自有运维人力，或商业版加厂商服务，两条路的总拥有成本要按三年算。一张卡片三个问题，五分钟能对任何一套 openGauss 环境完成定性——这就是设计哲学读法的实用形态。

本节要点回顾

• 默认值即价值观：口令复杂度、审计、主备形态的出厂默认，暴露了它服务的目标场景；
• 内核三角：性能、可用、安全分层强化，通过配置而非二选一协调；
• 产品三角：兼容降低迁移疼感，创新押注 MOT 与池化，自主是替代项目的硬指标；
• 社区三角：内核、工具、生态分组运营，排障时按层找责任边界；
• 工程建议：迁移期用足兼容特性，稳态后逐步回归应用层逻辑。

下一节解决一个更具体的问题：实例、数据库、模式、表空间这些词到底谁包含谁？术语坐标系不统一，多方会议就会各说各话。