Redis array：长开发过程的短篇故事

Source: Hacker News

antirez – 40 分钟前 · 3545 次浏览

我在一月的头几天开始着手为 Redis 开发新的 Array 数据类型。这个 PR 直到现在才合并到仓库，所以这段代码已经烹饪了四个月。我是兼职进行实现的（虽然很多周实际上是全职的；从键盘上抽身有时会很困难），即使在大语言模型出现之前，这个实现也完全可以在四个月内完成。变化在于，同样的时间里，我能够做更多的事。这就是事情的简短经过。

规范（第 1 月）

• 编写了一份详细的规范文档，内容包括：
  • 新数据类型的设计动机
  • 使用的 C 结构体以及稀疏表示法
  • 环形缓冲区和 ARINSERT 的数组光标的精确定义
• 最初手工起草规范，随后与 Opus 配对，之后转而使用 GPT‑5.3（随后是 GPT‑5.x）进行设计与开发。
• 规范在来回反馈、关于最佳设计的智力挑战、妥协以及避免过度工程的过程中不断演进。

实现（第 2 月）

• 开始使用 AI 辅助进行自动编程，并持续审查生成的代码。
• 发现最初的间接层次（目录 + 切片）不足以支持诸如 ARSET myarray 293842948324 foo 之类的命令，而不会产生巨大的内存分配。
• 将设计改为 切片密集目录的超级目录，每个目录指向数组切片（默认每个切片 4096 元素）。
  • 这仍然保持了“实际上是数组”的表示，满足了内存特性目标，并且使 ARSCAN 和 ARPOP 的运行时间与现有元素数量成比例，而不是与范围跨度成比例。

评审与优化（第 3 月）

• 逐行进行代码评审；AI 生成的测试覆盖了大多数情况，但表面的正确性并不保证最优。
• 发现了一些小的低效和设计错误，随后在 AI 帮助下手动重写了许多模块。
• 在各种场景下进行大量压力测试，增强了对实现稳健性和实用性的信心。

拓展思路：ARGREP 与正则表达式

• 在建模用例时，我把 Markdown 文件存入 Redis 数组，意识到它们非常适合作为集中式知识库。
• 于是诞生了 ARGREP，它需要正则表达式支持。
• 选用了 TRE 库（感谢 Ville Laurikari），因为它在时间或空间上对病态模式具有安全性。
• TRE 在 foo|bar|zap 之类的模式上表现不佳；在 GPT 的帮助下，我对库进行了优化，修复了潜在的安全问题，并扩展了测试套件。

反思

• 高质量的系统编程仍然需要全程参与，但 AI 为以下方面提供了安全网：
  1. 大量、繁琐的任务（例如后期添加和测试 32 位支持）。
  2. 一个虚拟的劳动力，用来捕捉复杂算法中的明显错误。
• 编写详尽的初始规范至关重要；它使得对 sparsearray.c 和 t_array.c 的逐行审查成为可能。

结论

我这里不再重复详细的使用案例——它们已在 PR 信息中记录：
Redis PR #15162

我认为是时候让 Redis 拥有一种数值索引成为语义一部分的数据类型了。希望 Array PR 能尽快被接受，社区能够从它带来的新用例中受益。欢迎提供反馈。谢谢。