战略: 写密集型路线图 — 外科手术式优化写路径 (group commit → 背压 → L0)

[NeverENG]

@

背景 / 定位锚点

BanDB 的定位是作品集项目, 核心叙事是「数据时代快速处理数据的工具」= 写密集型摄入 / 预存储层。

写密集场景的性能瓶颈是固定的几个点, 应聚焦把这几个点做实、做出可验证的 benchmark 故事, 而不是堆模块铺体量——作品集里「小而精」胜过「大而糙」。

现状盘点 (写密集型关键特性)

写密集型关键特性	BanDB 现状	影响
WAL group commit (批量 fsync)	❌ storage/zstorage/WAL.go 每次写都 file.Sync()	写吞吐头号瓶颈
Compaction pacing / 背压	❌ 无	持续高写入会 write stall, 吞吐断崖
L0 sublevels	❌ 无	L0 堆积是写密集特有痛点
真正的 leveled compaction	⚠️ 疑似只有 flush, 无分层 compaction	进阶项

行动清单 (按性价比排序, 每项独立 commit / 独立验证)

① WAL group commit — 最高性价比, 首推

• 现状: storage/zstorage/WAL.go 每条写单独 file.Sync(), 磁盘喂不饱。
• 改造: 攒一批请求 → 一次 fsync → 统一返回。
• 为什么先做: 改动小 (集中在 WAL 一处)、benchmark 数字肉眼可见地涨、是教科书级写吞吐优化, 简历叙事强 ("用 group commit 把写吞吐做了 N 倍")。
• 验收: storage/bench_test.go 写吞吐对比改造前后, 数字写进文档。

② Compaction pacing / 背压 — 第二步

• 做完 ① 写变快后, 下个瓶颈是 compaction 跟不上 → write stall。
• 引入 compaction 限速 / 背压机制, 平滑写入。

③ L0 sublevels / 分层 compaction — 进阶, 可选

• 改动最大, 留到最后; 也可仅在文档里写为已知 roadmap。

原则

• 不重构、不追体量, 聚焦写路径。
• 按 ①→②→③ 顺序, 每步独立 commit、独立可验证, 都往「快速处理数据」叙事加分。

下一步

拆出子 issue: 先做 ① WAL group commit 的具体改造方案 (几种实现风格 + 优缺点)。
@