D1 写入行数问题

[Tsuk1ko]

观察到 check_results 产生的写入行数为 3，AI 分析可能是 D1 统计会把索引写入也计入行数

按照这个统计来看，每个监控每天约产生 5.6k 行写入，而 D1 每天写入上限是 100k，也就是说 17 个监控就干到上限了，而用户如果部署了其他会产生较多写入的应用可能影响会更大

可能的改进方向

1. 下调写入频率

如果某监控一直正常，则可以每 3 / 5 分钟才写入一次延迟记录信息

若状态变化，则立即写入

影响：

• 状态页中近 60 次探测结果在有状态变化的情况下可能不再等间隔（受 up -> down 这类状态变化影响会立即写入）
• 24h范围延迟图表在上述情况下的数据处理逻辑

2. check_results 以时间为维度聚合储存

该想法较为激进

以时间为维度写入检查结果，将当前时间所有监控项的数据聚合到一行，储存 JSON TEXT Record<string, CheckResult>，这样写入行数只跟写入频率相关

影响：

• 数据读取
  • D1 内置 JSON 查询方法，在读取方面或许可以派上用场，并避免使用 JSON.parse
  • 若需要所有监控项的数据，实际上应该可以减少读取查询行数
  • 只需要单个监控线的数据时充分利用 D1 内置 JSON 方法
    • 获取所有数据后在客户端解析也是一种方案，但可能获取冗余数据并增加请求大小
• 数据储存
  • JSON.stringify 可能会增大 CPU 开销，或尝试使用 fast-json-stringify
  • 储存方式改变，这意味着旧数据需要迁移
• 改造成本
• 可能有其他坑

个人尝试改进

Tsuk1ko@61cee17

目前我尝试用 AI 实现了上述方案 2 的改造，并且也改造了快照等地方进一步降低 d1 写入量，目前优化到

• d1 写入 29k/天
• worker 请求 8.6k/天
• 增大了默认 batch size 以减少请求，但 CPU 时间仍在正常范围内（P50 2.9ms）
• 稳定性仍在观察
• 但未考虑旧版本迁移