暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

HOW2026复盘分享:晨章数据EloqData的NVMe+协程实践

晨章数据 2026-05-06
30

 

笔者常年关注存储架构演进,本次 HOW 2026 大会在济南山东大厦召开,晨章数据(EloqData)的刘言老师在 28 日上午带来的分享直接戳中了AI时代存储的核心痛点。听完这场分享,我对数据库使用的硬件有了新的认识:当PCIe 5.0 NVMe SSD已经做到330万IOPS时,我们应当考虑是否仍将软件架构止步于传统多线程模型。

01. AI时代存储面临三大暴击:数据爆炸、成本飙升、硬件错配

AI大模型和AI Agent的落地,正在从根本上重构存储的核心需求。传统存储架构面对新场景,已经出现了明显的断层。

第一暴击是数据量爆发。AI调用产生的中间态数据,从传统的KB级直接跃升到数百GB甚至TB级,多模态数据占比持续提升。以前一个数据库实例存几百GB就算大的,现在一个训练任务的临时文件就能占满整盘。

第二暴击是存储需求变化。数据规模增长的同时,业务要求低成本存储加快速查询,传统集中式存储的性能瓶颈和数据割裂问题越来越凸显。你不能既要马儿跑得快,又要马儿不吃草,但AI业务真的就是这么要求的。

第三暴击是硬件与软件的错配。PCIe 5.0协议的NVMe SSD已经能做到10GB/s以上的顺序读写、330万IOPS的随机读写,单机能挂载多块横向扩展,2027年三星还将发布新一代PCIe 6.0 SSD,性能再次翻倍。但传统软件架构根本压榨不出这些硬件潜力,存在3.5倍以上的性能浪费。这就好比你给一辆跑车装了个拖拉机的变速箱。

02. 传统架构的内存陷阱:为什么99%缓存命中率不再可持续

传统数据库架构重度依赖内存,要求99%以上的缓存命中率才能保证性能,一旦大量访问磁盘就会导致性能剧烈波动。这个模型在内存便宜的时候没问题,但今年内存价格持续上涨,企业扩容成本压力陡增。

从硬件层面看,PCIe 5.0 NVMe SSD的延迟已经降到微秒级,理论上完全可以承担更多的热数据访问。但传统多线程和多进程编程范式的上下文切换成本极高,一次系统调用上下文切换就要0到2微秒,纯CPU读磁盘的理想情况下,单核每秒仅能处理50万次请求。大量的CPU资源没有花在处理业务上,而是浪费在了内核调度里。

笔者之前做PostgreSQL高可用时也深有体会,后台的WAL归档、AutoVacuum任务一旦跑起来,线上业务的延迟就会出现毛刺。传统线程模型下,你几乎无法控制这些后台任务的CPU抢占,只能眼巴巴看着监控告警。

03. 协程重构IO密集型任务:从操作系统调度到用户态自治

晨章数据选择的方案是全链路协程改造。这个思路不是简单的技术炫技,而是针对IO密集型高并发任务的精准手术。

对比维度
传统线程模型
协程模型
调度主体
操作系统内核
用户态程序
上下文切换成本
0至2微秒/次
纳秒级/次
单核支持并发数
数百级
数十万级
后台任务可控性
低,内核调度抢占CPU
高,用户态主动让出
适用场景
CPU密集型任务
IO密集型高并发任务

协程的核心优势非常明确。上下文切换成本极低,可以批量发起异步IO请求从而减少系统调用次数。更重要的是,用户态调度能够精细控制后台任务。笔者在PG运维中最头疼的后台任务抢占问题,在协程架构里可以通过主动让出CPU来解决,线上业务和后台维护可以真正做到互不干扰。

这里要提醒一点:协程模型不是银弹。如果你的业务是纯CPU密集型,比如复杂数学计算或者大量内存排序,协程的优势并不明显,甚至可能因为用户态调度开销而适得其反。选型时一定要先做IO负载分析,确认是IO密集型高并发场景再考虑协程改造。

本文作者:严少安,PostgreSQL ACE, IvorySQL 贡献者,IvorySQL 专家顾问委员
公众号「少安事务所」,由 严少安 主笔,专注于数据 & AI 领域技术传播。
个人主页:https://shawnyan.cn/

04. 四层解耦架构:计算、缓存、日志、存储各自独立伸缩

晨章数据自研的存储架构做了四层完全解耦的设计,各层可以独立弹性伸缩。这种分层思路对于做云原生数据库或者信创私有云部署都很有参考价值。

架构层级
核心职责
独立扩展触发条件
典型技术实现
计算层
Parser、Planner、执行引擎
QPS增长、SQL复杂度提升
支持MySQL、PG、Redis、MongoDB协议
缓存层
分布式缓存、并发管理
热数据增多、读放大严重
可独立扩展内存节点
日志层
分布式WAL、事务顺序保障
写压力增大、吞吐瓶颈
单独加日志盘提升吞吐
存储层
数据长期持久化、副本管理
数据量增长、容量告警
独立扩展存储节点

读路径优先访问缓存层,未命中再访问存储引擎。写路径优先写内存直接返回,异步刷脏保证持久化。需要强一致性的场景可以先写日志再返回。各层完全独立伸缩,资源利用率比传统架构高30%以上。

这种设计对于信创场景特别友好。国产CPU和国产操作系统的组合往往资源有限,分层解耦后你可以按需扩容,不用为了加存储而被迫买一堆计算节点。

05. 存储引擎的针对性优化:让NVMe SSD只跑一次磁盘IO

为了适配NVMe的低延迟特性,晨章数据的存储引擎做了四项针对性优化,每一项都直击传统B树引擎的痛点。

第一项是索引扁平化。采用B树结构,上层先做数据分区,保证每个B树最多两层。根节点全部常驻内存,所有数据访问仅需1次磁盘IO,而且数据量在4K以内。这意味着绝大多数点查的延迟可以控制在几十微秒。

第二项是Copy on Write追加写。修改数据页时写新位置,再更新索引指针,避免锁竞争,保证数据一致性。这个思路和PostgreSQL的WAL机制以及ZFS的COW有异曲同工之妙,对于高并发写入场景非常有效。

第三项是异步批量合并写入。暂存脏数据后批量刷盘,减少写放大,提升写入效率。NVMe的4K随机写性能很强,但写放大控制不好会快速消耗SSD的PE周期,批量合并是延长硬件寿命的关键。

第四项是预索引系统。所有操作可追溯,保证元数据一致性。这一点对于金融、电信等强合规行业非常重要,审计来了你能拿出完整的操作链路。

06. 云上三层介质分工:EBS、NVMe、S3各得其所

晨章数据在云上的部署架构非常巧妙,完美平衡了成本、性能和可靠性。他们把三种存储介质做了明确分工,没有试图用一种介质解决所有问题。

介质类型
用途
核心优势
注意事项
云上EBS盘
写日志
高持久性、低成本扩展
禁止直接存储业务数据,IOPS上限低
本地NVMe SSD
对象存储缓存
低延迟、高IOPS
视为易失性介质,需配合持久化层
对象存储(S3)
最终持久化
无限容量、原生跨Region复制
用于主从复制,降低主节点压力

EBS盘仅用于写日志,因为日志数据量小,可以低成本扩展多块EBS盘提升写吞吐。本地NVMe SSD作为对象存储的高速缓存,视为内存延伸,大部分场景数据可以全部落在NVMe上,延迟仅几十微秒。对象存储作为最终持久化层,利用S3原生能力做主从复制和跨Region复制,新节点扩容不需要从主节点全量复制数据,主节点压力降低70%以上。

这个分工对于混合云部署很有启发。很多企业在信创私有云里也有类似的介质组合,比如用国产NVMe SSD做热数据缓存,用分布式对象存储做冷备,晨章数据的架构可以直接参考。

关于晨章数据EloqData

晨章数据(EloqData)是专注AI时代存储架构优化的技术厂商,核心团队来自微软、AWS、头部互联网公司,本次分享的存储架构代码已经全部开源,有对应的用户交流群可以技术答疑。产品适配国产化信创场景,支持主流国产CPU和操作系统,适合AI训练/推理、海量KV存储、高并发数据库等场景,相比传统内存方案成本降低10倍以上,性能仅下降20%以内。

https://github.com/eloqdata/eloqstore


Have a nice day ~ ☕

🌻 往期内容 ▼

👉 这里有得聊

如果对国产基础软件(操作系统、数据库、中间件)、AI、Vibe Coding、OpenClaw 、Hermes Agent 等感兴趣,可以加群一起聊聊。关注微信公众号:(少安事务所),后台回复[群],即可看到入口。如果这篇文章为你带来了灵感或启发,请帮忙『点赞、推荐、转发』吧,感谢!ღ( ´・ᴗ・` )~

 


文章转载自晨章数据,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论