28 深入专题：国产数据库内核剖析
openGauss、金仓、OpenTenBase 等国产 PG 系内核的技术差异。
A 国产数据库 PolarDB 能不能跑在 H 国产操作系统 openEuler 上？
文章讨论国产数据库与国产操作系统的适配问题：PolarDB（A 国产库）能否跑在 openEuler（H 国产操作系统）上，核心在于依赖库（glibc、内核参数、编译环境、驱动）的兼容性和官方认证。国产化『信创』要求数据库+操作系统+芯片全栈适配，跨厂商组合常遇到未认证、依赖不匹配、性能未调优等问题。答案是可跑但需要做依赖适配和参数调优，且最好用官方认证过的组合以保证支持。
ACE 装国产数据库花了 2 周，反映了国产数据库什么现状？
文章用一位 ACE（数据库专家）装某国产数据库耗时 2 周的经历，吐槽国产数据库在安装部署、文档、依赖、环境适配上的成熟度参差不齐。相比之下作者试自家产品很快装好，说明国产库之间的工程化程度差异很大。它点出的现状是：内核可能不错，但安装、运维、兼容性、文档这些『最后一公里』体验是国产数据库普遍短板，也是用户选型时最痛的环节。
Atlas 950 SuperPoD 登顶与『华为韬定律』是什么？
文章把华为 Atlas 950 SuperPoD 超级计算节点站上世界之巅的现象，类比为『华为韬定律』（借韬光养晦之意，指华为在算力/硬件上持续投入最终登顶）。它关联到国产数据库和 AI 算力的底座能力：国产芯片+国产操作系统+国产数据库全栈崛起是长期积累的结果，华为在昇腾/鲲鹏硬件上的突破为 openGauss 等国产数据库提供了算力支撑。
BemiDB 如何让 PolarDB PostgreSQL 提速 10 倍以上？
BemiDB 整合 PolarDB PostgreSQL 与对象存储/列式能力，针对 DataLake 场景做优化，实现 10x+ 提速。思路是让 PG 引擎直接高效读取对象存储（如 OSS）上的列式数据，利用并行扫描、谓词下推、列存压缩等减少 IO 和计算，把 PG 变成能直接查数据湖的引擎。这代表了『PG 内核 + 存算分离 + 列式』融合加速的国产演进方向。
HW 放弃 OpenGauss TP 售卖对用户是好还是坏？
文章分析华为放弃 OpenGauss 在 TP（事务处理）市场的售卖策略，对用户的影响。OpenGauss 本身开源，华为若收缩商业售卖，用户短期可能面临商业支持收缩、服务不确定性，但长期看开源社区和生态（如众多发行版）会继续演进。好坏取决于用户是否有自主运维能力：有能力的用户乐见其开源属性、成本更低；依赖原厂支持的客户则要重新评估支持保障。
OpenTeleDB 的 XStore 引擎如何解决 vacuum 抖动？
PG 原生 MVCC 下 UPDATE 会产生 dead tuple、写两份 heap 和 index page，导致表膨胀、vacuum 期间性能抖动 40% 以上。天翼云 OpenTeleDB 用 contrib/xstore 的 XStore 引擎实现『原位更新 + Undo 体系』：原地覆盖旧版本、用 Undo 保存旧值供回滚和旧快照，从而不再产生 dead tuple、不重复写页。效果是把 vacuum 抖动压到 5% 以内，是 PG 存储引擎的重要国产改进。
OpenTeleDB 的代码规模有多大？
OpenTeleDB 主源码 + contrib 合计约 256,572 行 C/C++，约为 PG 17 主干的四分之一，是精简后的实现，部分功能走 contrib 模块化。它由 XStore（存储引擎）、XProxy（代理）、XRaft（Raft 复制）等模块组成，基于 PG 内核做电信级增强，定位是面向电信场景的开源 PG 发行版。
OpenTenBase 的 CN/DN/GTM 三组件架构是什么？
OpenTenBase 是腾讯系、从 Postgres-XL 演进而来的分布式数据库（经 Postgres-XC→TransLattice→Postgres-XL 再到 OpenTenBase，最新 v2.6.0）。架构分三组件：CN（Coordinator）负责解析、重写和分布式规划，把 SQL 拆成多分片推到 DN；DN（DataNode）实际存储分片数据并执行；GTM（Global Transaction Manager）负责全局事务号、全局快照和全局序列。一个 SQL 要跨 CN→GTM→DN 协作，是 PG 系里真正的分布式数据库。
OpenTenBase 的代码规模和 GTM 为何是核心？
OpenTenBase 主源码约 17.8 万行 C/C++（主 src/，不含 contrib），其中 GTM 目录就占 76,237 行、约 42%，是最大的非标准 PG 代码块。GTM 负责全局唯一 64-bit GXID、全局快照（全集群 MVCC 一致）、全局序列（跨 DN nextval 一致）和 GTM 自己的 WAL 持久化。因为分布式一致性全压在 GTM 上，它的可用性和性能直接决定集群能力，是 OpenTenBase 与单机 PG 差异最大的地方。
PG 比 MySQL 快这么多为什么会让国产内核研发被『洗脑』？
文章反讽一种现象：某国产数据库内核研发人员认为『PG 比 MySQL 快这么多是不符合预期的』，暴露了对两者架构差异的误解。PG 和 MySQL 的并发模型、存储引擎、优化器能力不同，某些负载下 PG 更快是正常结果，不能用『MySQL 应更快』的预设来否定实测。文章提醒内核研发要尊重基准测试和架构事实，避免用偏见替代数据。
VexDB 容器里同时暴露 PG/openGauss/vastbase 意味着什么？
VexDB 是一个容器化体验方案，能在同一环境里暴露 PostgreSQL、openGauss、vastbase（海量数据的国产库）等多个引擎，方便快速对比和体验不同国产/开源数据库。它解决了国产数据库『装起来麻烦、试起来门槛高』的问题，用 docker 一键拉起多种内核做功能与性能对比，是选型和学习国产库的实用工具。
oGRAC 是什么，它和传统 PG 分布式数据库的核心区别在哪？
oGRAC 是华为开源的『开源版 RAC』，实现应用透明的多主强一致写入——任意节点都能执行 DDL/DML/DCL，所有节点看到同一份强一致数据，像用单机一样用集群，只要有任一存活节点集群仍可用。这与 PG 主从（单点写）、逻辑复制（应用层冲突检测）本质不同。核心在 DSS（分布式存储服务）+ DTC/DLS/DCS 三件套：DLS 分布式锁、DCS 分布式共识、DRC 分布式行缓存，配合共享存储实现存算分离多写。
oGRAC 的代码规模和多主恢复的工程难点在哪？
oGRAC 主源码约 88.8 万行 C/C++，比 PG 16 主干（约 110 万行）略小、比 openGauss（约 170 万行）小一半。多主核心在 pkg/src/cluster/ 下：dtc_recovery.c 单文件 10,217 行是整个项目最大文件，dtc_dcs.c（3,464 行，分布式共识）、dtc_dls.c（2,109 行，分布式锁）、dtc_dc.c（1,403 行，远程 page 缓存）。崩溃恢复是 82 个 API、涉及跨节点 redo 和主从切换，是工程上最难的部分。
openGauss 内核在 INSERT 上做了哪些极致优化？
openGauss 把一条 INSERT 拆成 8 个步骤优化：包括 NUMA 感知的 buffer/clog 分区、并行 redo、JIT 编译 LLVM IR 直接执行等，目标是亚毫秒级完成。对 MOT 内存引擎表，JIT 编译的 LLVM IR 直接执行且不进 WAL，旁路常规存储路径。在两路鲲鹏 128 核上跑出 150 万 tpmC，靠的就是这 8 个步骤里每个细节的极致优化（NUMA 亲和、内存引擎、并行恢复、JIT）。
openGauss 的代码规模和五大模块构成是什么？
openGauss-server 主源码约 49.7 万行 C/C++（不含 contrib/lib/tools），codegraph 索引出 4,967 文件、143,586 节点、543,067 边。内核按 5 大模块组织（存储、执行器、优化器、事务、恢复等），其中 MOT 内存引擎是最大亮点——内存行存、免 WAL、JIT 执行，专攻高并发 OLTP。openGauss 是国产顶级数据库内核的代表，从 PG 分叉后做了大量面向信创和高性能的定制。
『多个引擎一份存储』（CockroachDB/SequoiaDB）的架构意义是什么？
CockroachDB、SequoiaDB 等采用『多个引擎共享一份存储』的思路：计算引擎（SQL 层）与存储层解耦，多个计算节点/引擎访问同一份分布式存储，实现弹性伸缩和资源隔离。这与传统『每库自带存储』的单体架构不同，更接近云原生。对 PG 生态的启示是：可以把 PG 的 SQL 引擎接到共享存储上（类似 PolarDB 计算存储分离），兼顾 PG 生态兼容与弹性能力。
为了体验 OpenTeleDB 的 XStore，作者做了什么？
作者为体验电信 OpenTeleDB 开源的 PG XStore 存储引擎，专门做了一个 docker 镜像，一键拉起带 XStore 的 OpenTeleDB 环境，方便直接测试其原位更新+Undo 特性、对比 vacuum 抖动。这反映了国产库开源组件『体验成本高、缺少现成镜像』的现状，用容器降低门槛是社区推广的有效手段。
为什么说『千万别学国产数据库』？
这是一篇反讽/警醒性质的文章，核心观点是：国产数据库多基于开源（尤其 PG/MySQL）二次开发，内核门槛高、投入大、周期长，盲目跟风自研容易『重复造轮子』且难以超越上游；真正该做的是站在开源肩上做差异化（如存储引擎、分布式、兼容性），而不是从零写内核。文章用调侃语气提醒从业者理性看待国产数据库热，避免低水平重复建设。
对象存储计算引擎 hawq/gpdb 的思路是什么？
Hawq 和 Greenplum（GPDB）是基于 PG 的 MPP 分析型数据库，早期采用『计算与存储在 HDFS/对象存储分离』的思路：数据放分布式文件系统，多个 segment 并行扫描计算。这种存算分离架构支持弹性扩缩容和大规模并行分析，是 PG 体系里大数据分析引擎的代表。后来 GPDB 转向自管理存储，Hawq 融入 Apache 生态，但存算分离思想影响了后续云原生数据库设计。