nlp - Milvus 在 150K 条记录时 CPU 索引速度非常慢

Question

我们使用 Milvus 并使用默认配置进行 CPU 部署， 对于摄取到 milvus 中的每条新记录，我们都会在 milvus 内为此集合重建索引，但是我们发现构建索引所需的时间有所增加(当单个工作区中的记录达到约 150K 时)，大约需要半分钟

因此，我们删除了手动构建索引，让 milvus 基于 index_file_size 进行重建，但出现了一些问题，因为在禁用手动索引之前在另一个已正确索引的工作区中进行搜索变得比以前慢得多

所以我的问题是？

• 工作区中的索引会受到非索引工作区的影响吗？
• 为什么插入和构建索引需要这么长时间？
• 如何选择完美的index_file_size？ 您对于在生产环境中使用 cpu milvus 有什么建议吗？

Answer 1

我假设您使用的是 Milvus 1.x 我不熟悉“工作空间”这个表达，我假设您指的是集合或分区

对于你的第一个问题: 工作区中的索引会受到非索引工作区的影响吗？

我假设您在问:集合正在进行的索引任务是否会受到未建立索引的集合的影响。

答:当然可以，Milvus 1.x 是一个独立的解决方案，不同的任务共享相同的资源。尽管第二个集合没有被索引，但搜索任务仍然会占用大量资源，因为它是一个非常占用 CPU 资源的任务。

为什么插入和构建索引需要这么长时间？

插入时间应该不会太长，请检查时间是否花在网络IO上。构建索引是一项 CPU 密集型任务，可能会花费相对较长的时间，具体取决于数据大小、索引类型以及您用来托管 Milvus 的机器。如果时间太长，可以考虑使用GPU或者改用其他索引。

如何选择完美的index_file_size？您对于在生产中使用 cpu milvus 有什么建议吗？

如果没有连续添加数据，较大的index_file_size对搜索性能有很大好处。但是，如果有新添加的数据，您可能希望有一个较小的index_file_size，因为正在插入的段没有索引，这可能会损害整体搜索性能。

对于index_file_size对索引构建性能的影响，我们假设向量数量N，构建ivf索引的复杂度为O(θ * N)，θ为一个常数。总体成本不应受到index_file_size的影响。