mirror of
https://github.com/GreptimeTeam/greptimedb.git
synced 2026-05-25 01:10:37 +00:00
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
# Task 06 - 端到端验证与回归基线
|
||
|
||
## 任务目标
|
||
|
||
建立 remote dyn filter 的功能、一致性、可靠性和性能验证矩阵，证明该机制在带来 pruning 收益的同时，不会因异常路径破坏查询正确性。
|
||
|
||
## 主要落点
|
||
|
||
- `tests/`
|
||
- `tests-integration/`
|
||
- 分布式 query / datanode / region 相关测试目录
|
||
- 基准或 benchmark 脚本目录
|
||
|
||
## 前置依赖
|
||
|
||
- Task 01-05 完成最小可用实现。
|
||
|
||
## 实现范围
|
||
|
||
1. 功能测试:
|
||
- distributed hash join，小 build side 对大 probe side 产生远端 pruning
|
||
- 无法序列化表达式时自动降级且结果正确
|
||
- 初始 remote read 与后续 dyn filter update 使用同一个 `remote_query_id + filter_id` 逻辑 identity，并稳定绑定到对应 subscriber scan 集合
|
||
2. 一致性测试:
|
||
- update 乱序
|
||
- 重复 epoch
|
||
- complete marker 早到 / 晚到
|
||
- 仅部分 region 收到 update
|
||
- `remote_query_id` / `filter_id` 缺失或关联键不完整时安全降级，不串线到其他 query state
|
||
- datanode 本地 `is_used()` 类 eager cleanup 与 frontend unregister / TTL 兜底不会互相打架或造成误删
|
||
3. 可靠性测试:
|
||
- frontend 中途停止发送
|
||
- datanode 重启或 scan 提前结束
|
||
- query cancel 后状态释放
|
||
4. 性能验证:
|
||
- 高频小 update 与低频批量 update 对比
|
||
- 不同 `IN` cardinality 阈值收益曲线
|
||
5. 建立回归基线，为后续 Phase 2/3 演进提供对照数据。
|
||
|
||
## 推荐子步骤
|
||
|
||
1. 先补最小集成测试，证明“能工作且失败不影响结果”。
|
||
2. 再补乱序 / 幂等 / 清理类单测，把状态机语义锁住。
|
||
3. 最后增加 benchmark 或 profiling 脚本，比较不同更新策略的控制面开销。
|
||
4. 为日志和 metrics 增加断言，确保观测口径不会回归。
|
||
|
||
## 验收标准
|
||
|
||
- 至少一个 distributed join 集成测试证明远端 pruning 生效。
|
||
- 所有异常路径测试都证明查询结果仍然正确。
|
||
- 状态机相关测试覆盖乱序、重复、complete marker、超时回收。
|
||
- 有可重复运行的性能对照基线，能支撑是否继续推进 stream/batch 演进。
|
||
|
||
## 风险与注意点
|
||
|
||
- 只测 happy path 没有意义，remote dyn filter 的价值在于异常时也必须安全退化。
|
||
- 性能测试必须同时看收益和控制面成本，不能只看扫描量下降。
|
||
- Phase 2/3 若没有基线，后续优化很难判断是真提升还是只是在搬移开销。
|