本文作者付超Oracle ACE 与 PostgreSQL ACE 双认证专家PG 分会西安用户组核心成员。本文看点一句话结论IvorySQL 5.4 在 openEuler riscv64 平台上可原生编译、稳定运行软件层面无指令集兼容性缺陷具备作为去 IOE 替代数据库的基础条件。而性能这一项需要多说两句本次压测跑出的 663 ~ 750 TPS是在 128 核的机器上只点亮了不到 3% 算力、参数完全默认的情况下拿到的基线值。它反映的是 RISC-V 的单核算力现状而不是这台服务器的能力上限——换句话说差距是 CPU 给的不是数据库拖的。本文基于真实硬件实测沿着一条完整的链路往下走为什么难RISC-V 的内存模型和 x86 到底差在哪为什么这件事对数据库是生死线能不能编源码原生编译产出 RISC-V 原生二进制无闭源依赖、无需打补丁跑起来像不像Oracle 兼容层预加载运行无架构异常无段错误跑得快不快riscv64 TPS 663~750单核等效约 187 TPS/线程瓶颈在 CPU 不在软件00 为什么非要在 RISC-V 上测一遍数据库国产化替换走到今天芯片和操作系统这两层的替代路径已经比较清晰了。真正难啃的是数据库这一层——它之所以难不是因为代码量大而是因为一个数据库要同时扛住三件事并发原语自旋锁、Latch、原子计数器、无锁数据结构MVCC 可见性事务快照的正确性依赖于内存读写顺序崩溃恢复WAL 落盘顺序一旦被乱序执行破坏就是数据丢失。你会发现这三件事全都踩在同一个敏感点上——内存一致性模型。而这恰恰是 RISC-V 和 x86 真正不一样的地方。所以能不能编译通过从来不是重点编出来之后事务是不是还对才是重点。01 先讲清楚RISC-V 上的数据库难在哪在贴命令之前先花一分钟说说这次实测的题面。理解了这几条后面的测试数据才有意义。内存模型这台机器的性格和 x86 不同x86 采用的是TSOTotal Store Order内存模型——它对程序员相当友好Store-Load 之外的内存重排基本被硬件挡住了。RISC-V 默认采用的是RVWMOWeak Memory Ordering允许更多种类的内存访问重排序需要软件显式地用fence、amo原子内存操作指令来划定边界。这个差异对普通应用几乎无感但对数据库是生死线。PostgreSQL 系的代码里散布着内存屏障、原子 CAS、自旋锁如果这些原语在 RVWMO 下被错误翻译或错误实现典型症状就是偶发的事务可见性错乱、难以复现的死锁、以及在高并发下 TPS 突然塌方。所以本次测试最有价值的一条结论不是能跑而是跑得不别扭——没有出现锁竞争异常也没有出现内存屏障相关的性能塌陷。指令集与 ABI实测环境的硬件能力基线是rv64gcUCB RISC-V RVC 压缩指令lp64d双精度浮点 ABI编译器 gcc 12.3.1。这是一套主流且完备的 64 位 RISC-V 组合浮点、压缩指令、原子操作都在。有一点算是幸运RISC-V 和 x86 同为小端序。这省掉了数据库里大量与字节序相关的适配工作想想看如果换成大端所有磁盘格式、WAL 记录、网络协议解析都要重新过一遍。工具链生态是否齐备源码编译的第一道坎其实是依赖。实测中构建 PostgreSQL 系数据库所需的关键依赖——gcc、libicu、bison、flex、perl、readline、zlib——在 openEuler 24.03 LTS 官方仓库里都有 riscv64 版本直接从dnf拉取即可不需要自己交叉编译任何依赖。这条看似平淡实际是能不能自主构建的分水岭。02 环境一台 128 核、8 NUMA 的国产服务器先把测试机亮出来。这是一台典型的大机器配置远超常规验证需求也正因为如此后面性能章节的解读才有了关键参照。[highgoopeneuler-riscv64 ~]$ lscpu Architecture: riscv64 Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 NUMA: NUMA node(s): 8 NUMA node0 CPU(s): 0-7,16-23 NUMA node1 CPU(s): 8-15,24-31 NUMA node2 CPU(s): 32-39,48-55 NUMA node3 CPU(s): 40-47,56-63 NUMA node4 CPU(s): 64-71,80-87 NUMA node5 CPU(s): 72-79,88-95 NUMA node6 CPU(s): 96-103,112-119 NUMA node7 CPU(s): 104-111,120-127 [highgoopeneuler-riscv64 ~]$ uname -a Linux openeuler-riscv64 6.6.127-0.0.0.0.riscv64 #1 SMP Wed Jul 15 02:08:54 CST 2026 riscv64 riscv64 riscv64 GNU/Linux [highgoopeneuler-riscv64 ~]$ free -g total used free shared buff/cache available Mem: 250 2 247 0 1 247 Swap: 0 0 0环境体检的几条关键读数项目实测值对本次验证的意义系统openEuler 24.03 LTS内核 6.6.127国产 OS 国产指令集完整替换栈CPU 拓扑128 核 / 8 个 NUMA 节点每节点 16 核内存访问有跨节点代价数据库对此极其敏感内存250 GB基本全空闲大内存机器默认参数会严重浪费Swap0压测期间不存在换页抖动数据可比性高存储NVMe 0.9 TB单盘根分区仅 4.6 GB数据目录需另挂大容量分区这里有一条容易被忽略但很关键的信息这台机器没有启用 Swap。这意味着压测过程中不会出现内存换页带来的 TPS 抖动663 ~ 750 这组数字是干净的——但它同时也意味着一旦内存配置失当程序没有任何缓冲余地。03 编译与部署三条命令零补丁去 IOE 替代的首要前提不是数据库功能多强而是它能不能脱离闭源二进制包在国产硬件指令集上自主编译部署。如果连源码都编不过后面所有验证都无从谈起。实测结果很干脆完整源码编译一次通过没有打任何补丁没有改动一行源码。第一步装依赖openEuler 仓库直取无需交叉编译sudodnfinstallgcc icu libicu libicu-devel bison flex perl\readline readline-devel zlib zlib-devel-y第二步拉源码、切分支gitclone https://github.com/IvorySQL/IvorySQL.gitcdIvorySQLgitcheckout-bIVORY_REL_5_STABLE origin/IVORY_REL_5_STABLE第三步编译安装-j32并行编译./configure--prefix/usr/local/ivorysql/ivorysql-5make-j32makeinstall第四步初始化并启动bin/initdb-D/opt/postgresql-19.3/ivorysql-5.x/data/# 输出节选The database cluster will be initialized with localeen_US.UTF-8.The default database encoding has accordingly beensettoUTF8.Data page checksums are enabled.# 数据页校验和默认开启selecting defaultshared_buffers... 128MB# ← 记住这个值第 05 节要用creating configuration files... ok running bootstrap script... ok performing post-bootstrap initialization... ok syncing data to disk... ok Success. bin/pg_ctl-D/opt/postgresql-19.3/ivorysql-5.x/data/-llogfile start waitingforserver to start....doneserver started整个过程没有任何架构相关的报错。产出的是 RISC-V 原生二进制UCB RISC-V, RVC, double-float ABI, lp64d不带任何闭源依赖。部署验收项全部通过✅ initdb 数据库初始化正常✅ pg_ctl 启停实例正常✅ 可开启数据页校验和checksums✅ 可配置 UTF-8 字符集✅ 可接入 IvorySQL Oracle 兼容扩展库✅ OS 用户与数据库超级用户映射正常✅ TCP 网络连接、共享内存、NVMe 存储读写无架构异常关键结论不存在指令集层面的底层兼容障碍。IvorySQL 5.4 可以完全基于国产 RISC-V 硬件自主构建不依赖闭源厂商预编译包满足去 IOE 的基础部署诉求。04 Oracle 兼容层去 IOE 迁移方案的地基Oracle 语法兼容是 IvorySQL 的核心价值也是很多传统 Oracle 迁移去 IOE 选型时最关注的模块。如果兼容层在新架构上崩溃那整个迁移方案就不成立。这里有个容易被低估的技术细节Oracle 兼容层不是一段独立的翻译脚本而是通过扩展预加载的方式深度挂进数据库内核的解析器、执行器和共享内存区。这意味着它和内核共用同一套内存屏障与原子原语——第 01 节提到的弱内存模型风险在兼容层这里同样存在甚至更集中它要在shared_preload_libraries阶段完成初始化任何地址对齐、结构体布局或原子操作的架构差异都会在实例启动时直接暴露成崩溃。所以兼容层能不能在新架构上干净加载并稳定运行实际上是对数据库整体架构适配质量的一次高压检验。测试中将以下三个扩展预加载到shared_preload_librariesgb18030_2022国标编码扩展liboracle_parserOracle 语法解析器ivorysql_oraOracle 兼容核心模块riscv64 平台验证结果扩展库可以正常加载实例启动无异常SQL 执行过程中无段错误segfault、无崩溃整套 SQL 业务用例运行期间Oracle 解析兼容模块未出现架构相关异常一句话兼容层的地基是稳的。对 Oracle 迁移选型来说这是最有分量的一条结论——它意味着后续在 RISC-V 上做业务 SQL 全量回放是可以期待的。注意点contrib 组件需手动补齐IvorySQL 源码编译默认没有完整编译 contrib 组件btree_gin、intarray、amcheck等社区扩展未安装。执行make -C contrib install编译安装后可解锁更多扩展能力进一步对齐生产环境能力集。05 性能先看清楚这个差距是谁给的兼容性验证通过后性能是绕不开的话题。这一节我们把数字拆开看。5.1 原始数据基于 pgbench 压测8 客户端 / 4 线程 / 30 秒平台TPS说明riscv64本次实测663 ~ 750shared_buffers 默认 128MB未做调优x86同内核基线约 1600同等压测参数单看这两行容易得出RISC-V 只有 x86 一半的结论。但把测试条件摊开这个结论就不成立了。5.2 把这组数字的边界标出来观察维度实测值解读并发线程4 个 OS 线程机器有 128 核本次只动用了约 3% 的算力单线程等效 TPS≈ 187750 ÷ 4x86 同口径约 400比值 ≈ 0.47shared_buffers128 MB占 256 GB 内存的0.05%几乎完全默认NUMA8 节点未做绑定存在跨节点内存访问开销Swap0无换页抖动数据可比性高存储NVMe磁盘不是瓶颈换句话说663 ~ 750 TPS 不是这台服务器的性能而是这台服务器上 4 个 RISC-V 核 全默认参数下 pgbench 的性能。它是一条基线不是上限。5.3 差距拆到单核上性质就清楚了把 TPS 摊到线程riscv64 ≈187 TPS/线程x86 ≈400 TPS/线程比值约0.47。这个比值与 RISC-V 处理器和主流 x86 服务器处理器在单核 IPC × 主频上的现实差距是同一量级。也就是说——软件层没有额外加价。这一点值得反复强调。如果 IvorySQL 在 RISC-V 上存在架构相关的性能缺陷——锁自旋异常、内存屏障失效、cache line 对齐问题、原子指令劣化——那么单核效率会比硬件差距更差而且通常伴随 TPS 剧烈波动。而实测的 663 ~ 750 区间平稳没有性能塌方没有锁竞争异常没有内存屏障相关的退化。这就是本节的核心结论性能差距来自 RISC-V 单核算力不来自数据库软件。对于以兼容可用为目标的验证来说这是比 TPS 绝对值更重要的结果。5.4 更值得期待的是这台机器还没被真正用起来4 个线程 / 128 核意味着这台服务器的绝大部分算力在本次压测中处于闲置状态。真正的性能故事要等下面这几个维度逐一验证之后才完整并发扩展性最关键——把客户端/线程提到 64/64 甚至 128/128观察 TPS 是否随核数近似线性增长。这是衡量一台 RISC-V 服务器能否扛住生产数据库的核心指标也是目前最值得补的一组数据。内存维度——shared_buffers从 128MB 调整到内存 25% 量级约 64GB。当前配置下缓存严重不足这部分提升空间最大。NUMA 维度——8 个 NUMA 节点需通过numactl做内存绑定与进程亲和避免跨节点访问惩罚。数据库对 NUMA 的敏感度远高于一般应用。页表维度——配置 HugePages 大页减少 TLB miss。WAL 与检查点——调整wal_buffers、max_wal_size、checkpoint_*参数优化写入路径。存储维度——注意当前根分区仅 4.6 GB已用 74%生产部署必须为数据目录规划独立的大容量 NVMe 分区。5.5 这条基线的价值663 ~ 750 TPS 这个数字本身不算亮眼但它有一个不可替代的价值它是可比对的。同参数、同内核、跨架构唯一的变量是 CPU。有了这条基线后续每一次调优、每一次版本迭代都能清楚地知道改进来自软件还是来自硬件——这比一个孤立的、经过精心调优的漂亮数字有用得多。06 兼容性总结与落地建议兼容性总览评估项兼容结论备注riscv64 源码编译部署✅ 完全兼容原生二进制无闭源依赖零补丁Oracle 兼容扩展模块✅ 可用预加载运行无架构问题无段错误标准 SQL、事务、并发✅ 完全兼容上游内核核心特性全部生效性能压测基线✅ 无软件层损耗差距源于单核算力非架构缺陷contrib 社区扩展⚠️ 需手动编译安装默认未构建补齐即可总体判断IIvorySQL 5.4 在 RISC-V 国产硬件上软件层面兼容可用没有发现指令集相关功能性缺陷具备作为去 IOE 替代数据库的基础条件。落地实践建议1. 编译阶段完整编译 contrib 模块部署时执行make -C contrib install补齐btree_gin、intarray、amcheck等社区扩展对齐商用数据库周边工具能力。2. 性能调优大内存服务器不要用默认参数256GB 内存的 RISC-V 服务器shared_buffers默认 128MB 严重浪费资源。建议调整至内存 25% 左右配置 HugePages 大页并针对 8 NUMA 节点做内存绑定。同时建议补一组高并发如 64/128 线程压测把设备的并发扩展能力测出来。3. 迁移评估Oracle 兼容模块优先做业务回放Oracle 迁移场景优先验证ivorysql_ora兼容模块对业务 SQL 的覆盖度在 RISC-V 环境做全量业务回放测试确认语法兼容率和性能表现后再推进生产迁移。写在最后去 IOE 不是简单的硬件替换而是软硬件栈的整体适配。本次实测证明IvorySQL 数据库可以很好地跑通 RISC-V 国产指令集——从源码编译到 Oracle 兼容层从基础事务语义到并发压测软件层面没有发现指令集相关的功能性缺陷。性能这一项我们希望被这样理解在 128 核的机器上只用了 4 个线程、参数全默认、缓存只给了 0.05%跑出了 663 ~ 750 TPS 且全程平稳——这不是一台 RISC-V 服务器的上限这只是一条干净的起跑线。差距在芯片不在我们的代码里而算力这块地还空着 97%。但生产落地除了数据库本身还需要配套运维工具、备份监控、中间件驱动共同完成适配。真正的去 IOE是每一层都能自主可控、每一个环节都能真实跑通。数据库这一层IvorySQL 5.4 在 RISC-V 上已经交出了一份合格的答卷。