Milvus 和 Weaviate 等向量数据库通过结合自定义存储引擎、内存映射文件和分布式系统来处理向量存储和索引。具体实现因平台而异，但两者都优先考虑高效的数据访问和可扩展性。以下是它们的方法概述：
存储机制 Milvus 采用分布式架构，将存储与计算分离。它依赖对象存储（例如 Amazon S3、MinIO）来持久化原始向量数据和元数据，而索引和查询结果等中间数据则使用内存映射文件进行管理。这种设计允许 Milvus 通过将大型数据集卸载到经济高效的云存储来水平扩展，同时将频繁访问的数据保留在内存中以实现低延迟查询。例如，执行查询时，Milvus 会通过内存映射文件将相关的索引段加载到内存中，避免了完整的文件读取。另一方面，Weaviate 采用基于 LSM（日志结构合并）树的自定义存储引擎，该引擎将写入操作批量处理到不可变文件中，并在后台进行合并。这种方法优化了写入密集型工作负载，同时实现了高效的压缩。Weaviate 还支持可插拔的后端，例如基于磁盘的存储或 S3，用于快照，从而在性能和持久性之间取得平衡。
索引策略 两种数据库都使用近似最近邻 (ANN) 索引来加速相似性搜索。Milvus 支持多种索引类型（例如 IVF、HNSW、DiskANN），并将索引创建与存储解耦。索引单独构建，并在查询期间加载到内存中，通常使用内存映射文件来减少开销。例如，Milvus 中的 HNSW 图存储在内存中以实现快速遍历，但在空闲时可以持久化到磁盘。Weaviate 默认为内存中的 HNSW 索引，但也支持基于磁盘的 ANN 替代方案，例如 Spotify 的 Annoy。其基于 LSM 的存储支持增量索引更新，新的向量被添加到预写日志中，并在压缩期间合并到主索引中。这避免了为了小更新而重建整个索引，提高了写入效率。
底层基础设施 Milvus 利用分布式系统实现可扩展性。它使用 etcd 进行元数据管理，使用对象存储处理批量数据，并使用 Kafka/Pulsar 等消息队列处理流式更新。这种模块化设计使其能够跨集群处理大型数据集，同时通过内存映射索引访问保持低延迟查询。Weaviate 则选择更简单的单节点架构，并支持可选的复制。其 LSM 引擎在一个统一的层中处理向量存储和索引，从而降低了小型部署的复杂性。两个系统都使用内存映射文件来连接磁盘和内存，从而无需将整个数据集加载到 RAM 中即可实现快速访问。例如，Milvus 可以直接从磁盘映射 HNSW 图段，而 Weaviate 的 LSM 树则使用内存映射来加速压缩和查询。这些选择反映了可扩展性（Milvus）与简单性（Weaviate）之间的权衡，同时确保了高效的向量操作。