Redis新数组数据类型开发发布情况antirez 10小时前发布了关于 Redis 数组类型开发的相关内容已有 54242 次浏览。漫长的开发历程1月初antirez 开始为 Redis 开发新的数组数据类型直到现在相关的 Pull RequestPR才被合并到代码库历经四个月打磨。他是以半工半读的状态进行开发的即便在大语言模型LLM出现之前可能也需要四个月完成实现但现在能在同样时间里完成更多工作。第一个月撰写规格文档第一个月antirez 撰写了规格文档内容涵盖新数据类型的设计原理、C 语言结构体、采用的稀疏表示法以及环形缓冲区和 ARINSERT 操作中数组游标的确切语义。一开始手动撰写冗长的规格说明之后先与 Opus 协作等 GPT 5.3 发布后完全转向使用 Codex 进行设计和开发此后在系统编程任务中只使用 GPT 5.x。借助人工智能规格文档有了很大改进。第二个月代码实现与改进从第二个月开始采用自动编程方式开始实现代码并不断审查。后来发现选择的间接层级有误原本采用的两层目录 切片稀疏和密集结构不够。在人工智能支持下决定更进一步当达到特定条件时数据结构会在内部改变形态变成由切片密集目录组成的超级目录这些目录还指向实际的数组切片默认每个切片包含 4096 个元素。这种设计保留了期望的内部“实际上是数组”的表示形式具备所追求的内存特性。同时对于 ARSCAN 和 ARPOP 操作扫描现有数组所需的时间与现有元素数量成正比而不是与范围跨度成正比。第三个月压力测试与重写接下来逐行阅读所有代码数据类型有大量测试得益于人工智能。但发现存在许多小的效率问题和设计错误于是在人工和人工智能辅助下对许多模块进行重写。完成后在第三个月对实现进行各种不同方式的压力测试逐渐有信心认为它稳定、实用且设计精良。实现 ARGREP 及相关优化在模拟使用场景时将 Markdown 文件存入 Redis 数组意识到可以拥有集中化的 Markdown 文件知识库决定实现 ARGREP且想要支持正则表达式。最终选择了 TRE因为在 Redis 中使用正则表达式需确保在时间和空间上不会出现病态模式。但 TRE 在匹配 foo|bar|zap 这种模式时效率很低于是在 GPT 帮助下对其进行优化修复潜在安全问题并扩展测试。开发感悟与期望对于高质量的系统编程任务仍需全身心投入但人工智能保障了大规模任务和确保复杂算法无明显错误。撰写最初的大型规格文档和逐行审查 sparsearray.c 和 t_array.c 并修改不合适的地方都很关键。antirez 坚信 Redis 是时候拥有将数值索引作为语义一部分的数据类型希望数组 PR 能尽快被接受欢迎大家提供反馈。