feat: 边缘查询 scan + 谓词下推——只回传命中切片（方向 B，热窗口）

[NeverENG]

背景（采集员痛点 #3：查不动数据）

此前只有 PUT/GET/DELETE，想「把刚才 10s 内 az>9.9 的帧捞出来只传这一段」做不到。本 PR 把边缘本地查询 + 只回传命中切片端到端跑通。

范围（已与用户确认：热窗口）

v1 扫 MemTable 未刷盘热数据——正好是采集员最常查的「最近窗口」。已刷盘到 SSTable 的历史数据为 Phase 2（需把 mergeIterator 泛化+跨层新值优先+并发快照，已在代码注释标注边界）。

改动（4 个原子 commit）

1. storage MemTable.ScanRange：闭区间升序、firstGTE 定位、2 路归并 active(最新) 覆盖 dirty、跳墓碑、fn 可提前停；全程持读锁（热窗口扫描有界）
2. pkg/predicate：最小字段谓词 field op value（> >= < <= == !=，数值/字符串自动判别），纯函数
3. pkg/proto + service：SCAN msgID + wire 编解码（server/client 共用）+ KVServer.Scan（谓词下推、命中拷贝、10000 封顶并告警）+ 路由注册 + metrics.Scans
4. client：SendScan + 交互式 scan <start|-> <end|-> [field op operand]

差异化

谓词在服务端下推，只把命中切片回传——这是「GB→MB」的核心，也是 MCAP/Zenoh/COS 都不在采集入口做的那件事。

测试

• 单测：ScanRange（范围/墓碑/active 覆盖 dirty/提前停）、predicate（13 例）、proto 编解码往返
• 端到端集成测试：写 5 帧 IMU → scan [imu:dev0:100,imu:dev0:299] az>9.9 → 只回 2 条命中、越界设备 dev1 被范围排除
• go build ./... 通过，既有测试无回归

用法：

> scan imu:dev0:100 imu:dev0:200 az > 9.9
命中 2 条:
  imu:dev0:150 = {"az":9.95}
  imu:dev0:200 = {"az":10.2}

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@NeverENG, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 30 minutes and 17 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: fcf7118d-63c3-481b-a58e-d55eab122a55

📥 Commits

Reviewing files that changed from the base of the PR and between bb79547 and 83ad15b.

📒 Files selected for processing (21)

• Server/server.go
• Server/server_pprof.go
• client/client.go
• client/interactive.go
• config/config.json
• config/global.go
• config/global_test.go
• network/banNet/wire_scan_test.go
• pkg/metrics/metrics.go
• pkg/predicate/predicate.go
• pkg/predicate/predicate_test.go
• pkg/proto/codes.go
• pkg/proto/scan.go
• pkg/proto/scan_test.go
• service/fsm.go
• service/router.go
• service/scan_integration_test.go
• storage/engine.go
• storage/istorage/IMemTable.go
• storage/zstorage/memtable.go
• storage/zstorage/scan_test.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/edge-scan

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🐯 BanGD 数据库内核评审

整体风险：🟡 中

变更总结：本 PR 在 BanDB 存储引擎的热路径——MemTable 层新增了范围扫描（ScanRange）功能，并配合前端的谓词下推（predicate）、wire 编解码、交互式客户端与网络包上限调整，端到端实现了「边缘本地范围查询 + 服务端筛选后只回传命中切片」的能力。

核心改动集中在四层：

1. 存储层：MemTable.ScanRange——在 MemTable 的 two-list 结构（active + dirty）上做双向归并扫描，firstGTE 跳表定位，闭区间升序迭代，跳过墓碑（value==nil），fn 可提前停止；全程持读锁。
2. 谓词层（pkg/predicate）：纯函数式的单字段谓词引擎，支持 > >= < <= == !=，按操作数类型自动分流（数值比较 vs 字符串相等）。
3. 协议与网络：proto.ScanRequest/proto.ScanEntry 编解码，KVServer.Scan（谓词下推 + 命中拷贝 + 10000 条上限），MsgScan 路由注册；MaxPackageSize 从 1KiB 提升至 16MiB。
4. 客户端：Client.SendScan + 交互式 scan 命令。

注释已标注 Phase 2 边界：历史 SSTable 数据暂未接入，当前仅扫 MemTable 热窗口。

本评审不阻塞合入；架构级建议以 Issue 形式跟踪，普通问题在下方内联列出。

架构问题（共 4 项）

• [锁] ScanRange 全程持读锁阻塞写入与刷盘 storage/zstorage/memtable.go → 🐯 [锁] ScanRange 全程持读锁阻塞写入与刷盘 · memtable.go #146
• [性能] 谓词下推前全量扫描再过滤，未做索引剪枝 service/fsm.go → 🐯 [性能] maxScanResults=10000 硬编码，大范围扫撑爆单次响应 · fsm.go #145
• [内存] Scan 结果拷贝堆分配无上限管控 service/fsm.go → 🐯 [内存] Scan 结果拷贝堆分配无上限管控 · fsm.go #147
• [并发] firstGTE 未处理 dirty 为空场景下的并发安全性 storage/zstorage/memtable.go → 🐯 [并发] firstGTE 无锁遍历跳表，并发写入时出现越界 · memtable.go #143

普通问题（共 3 项）

🛑 [阻塞 · 逻辑错误] pkg/proto/scan.go:83 DecodeScanResponse 空条目时解包逻辑可导致越界

• 当 count == 0 时，DecodeScanResponse 在 off = 1+statusLen+4 位置返回空切片，且循环体不执行，这是正确的。但当 entries 从 EncodeScanResponse 编码时传入了 nil（而非 []ScanEntry{}），编码侧 len(nil)=0，编码正常；解码侧也能正常处理。不过若 count > 0 但 payload 在条目数据中间被截断，off+8 > len(payload) 检测在循环内会触发。目前代码已有 off+8 > len(payload) 检查，是安全的。但 keyLen < 0 || valueLen < 0 的检查在 int(uint32(...)) 下不可能为负——uint32 总是非负，int 转换后也不会负。这个检查实际上是多余的（但无害）。
• 建议：移除 keyLen < 0 || valueLen < 0 死检查，或改为 keyLen == 0 && valueLen == 0 时的异常处理（如果业务上不允许空 key）。

💡 [建议 · 逻辑错误] pkg/proto/scan.go:68 DecodeScanRequest 的 operand 切片包含不可预见的尾部数据

• DecodeScanRequest 中 operand := data[off:] 取剩余全部字节。这在理论上是正确的——operand 就是请求尾部剩余。但若请求格式有额外扩展字段或填充被追加到尾部未在 scanReqHeaderLen 中描述，operand 会错误吞掉这些字节。当前协议下这是设计如此（operand 是变长剩余部分），但应备注此项约定。
• 建议：在包注释或 const scanReqHeaderLen 旁注明「operand 占 request payload 剩余全部字节，无显式长度字段」。

💡 [建议 · 错误处理] client/interactive.go:181 parseOp 不处理操作数中有空格的分词问题

• handleScan 用 strings.Fields 分词后，operand 从 parts[5:] 用 strings.Join 拼接。但如果操作数本身包含空格（如 az != "some long value"），Fields 会把值拆成多个 token，parts[4] 不会是完整的 operator 而可能被误认为是 operand 的一部分。这是 CLI 分词的固有限制，当前不影响（数字操作数无空格），但未来扩展时会有歧义。
• 建议：考虑在 PR 描述或注释中注明当前 scan CLI 的操作数不支持内部空格；或改为更鲁棒的解析方式。

---

_{本次评审消耗 token：共 323462 tokens（输入 303072，输出 5926，缓存命中 14464，缓存写入 0）｜维度 [concurrency, memory, lock, storage, performance]｜对抗式复核 3 票/条，过滤疑似误报 0 条}