OpenData Vector：MIT 许可证的对象存储向量搜索

生成式 AI 和大型语言模型（LLM）的兴起使得需要一种能够线性扩展且不具备传统向量数据库相同成本负担的向量数据库概念。OpenData Vector 引入了一种新的向量搜索方法，利用对象存储作为主要存储层，有效地将计算与存储解耦，提供一种可扩展的、MIT 许可证的替代方案，以取代专有的向量搜索引擎。

OpenData Vector 的架构

OpenData Vector 的核心设计旨在解决向量数据库的主要瓶颈：高性能存储的成本和规模。通过使用对象存储（例如 AWS S3、Google Cloud Storage 或 Azure Blob Storage），系统使用户能够维护大规模的嵌入数据集，而无需通常用于高性能搜索的昂贵 SSD 支持基础设施。

这种计算与存储的解耦允许独立扩展。如果搜索量增加，可以添加更多计算节点来处理查询负载，而无需在多个昂贵的磁盘上复制整个数据集。相反，如果数据量增长，存储成本仍然保持低廉，因为对象存储相较于高性能块存储要便宜得多。

性能与实现细节

虽然对象存储本质上比本地 SSD 更慢，OpenData Vector 实施了降低延迟的策略。该架构遵循将索引与数据分离的模式，索引被缓存或存储在更高性能的层中，以确保查询结果能够快速返回。

这种方法类似于其他高性能向量搜索引擎（如 Turbopuffer）中看到的架构模式。目标是通过高效的索引和内存管理，实现查询的高吞吐量，同时保持搜索结果的准确性。

社区讨论与关键考虑因素

发布后，社区提出了若干关键问题，涉及性能权衡以及项目当前的成熟度。

性能差距

主要关注点之一是 OpenData Vector 与高度优化、硬件加速系统的比较。正如社区成员 @oliverio 所指出的，某些专有系统在硬件和固件层面拥有显著的优化，这可能导致性能差距。OpenData Vector 面临的挑战是将这些优化扩展到开源项目中，同时保持对象存储的通用性。

对象存储 QPS 的成本

另一个讨论点围绕请求速率的成本。普遍的看法是，由于 GET 和 PUT 操作的请求费用，如果每秒查询次数（QPS）极高，对象存储可能会变得昂贵。

“我一直认为，如果 QPS 数字很高，对象存储相较于‘普通’ SSD 会非常昂贵。”

为了解决此问题，基于对象存储的系统通常采用积极的缓存层，或在数据提交到存储层之前在数据库服务器上进行大量预处理。通过减少对对象存储的直接调用次数，这些系统能够兼顾存储的成本效益和本地磁盘的性能。

结论

OpenData Vector 为希望避免供应商锁定并保持对嵌入数据控制的用户提供了一个有吸引力的 MIT 许可证替代方案。通过将向量搜索引擎迁移到对象存储，它挑战了传统的昂贵高性能存储需求模型，使大规模向量搜索对开发者和 MIT 许可证的软件项目更加易于获取。