Milvus在150 K记录的CPU上的索引速度非常慢。

Question

我们使用milvus的默认配置来部署CPU，我们正在为这个集合重建milvus内部的索引，但是我们看到构建索引所需的时间(当单个工作区中的记录达到大约150 K时)增加了大约半分钟。

因此，我们删除了手动构建索引，以便让milvus基于index_file_size进行重建，但是在另一个工作空间中进行搜索时，在禁用manuall索引变得比以前慢得多之前，搜索是正确的。

所以我的问题是？

• 在工作空间中的索引会受到非索引工作的影响吗？
• ，为什么插入和构建索引要花很长时间？
• 如何选择完美的index_file_size？你对与cpu milvus在生产上的一般工作有什么建议吗?

Answer 1

我假设您正在使用Milvus1.x，我不熟悉“工作区”表达式，我假设您是在引用集合或分区

关于你的第一个问题：can index in a workspace be affected by non indexed workpsace ?

我假设您是在问:一个集合的持续索引任务是否会受到未被索引的集合的影响。

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

why inserting and building the index take this very long time ?

插入时间不应占用很长时间，请检查是否花在网络IO上。构建索引是一项非常密集的CPU任务，它可以占用相对较长的时间，这取决于数据的大小、索引的类型以及用于托管Milvus的机器。如果时间太长，可以考虑使用GPU或切换到其他类型的索引。

how to choose the perfect index_file_size ? do you have any suggestions in general working with cpu milvus in production ?

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

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