More information about milvus operation detail

[yhmo]

各种操作对查询操作的影响

（一）插入操作对查询的影响

• 对于同一客户端，插入操作是阻塞操作，只有当插入操作完成后才能调用查询接口，因此两种操作不会互相影响。
• 对于多客户端，假设客户端a频繁的插入操作，客户端b同时执行查询操作，milvus服务处理这些插入数据时会消耗部分CPU资源，因此会影响客户端b的查询性能。
• 插入数据后为了保证数据落盘，有时会调用flush操作，该操作是阻塞操作，会产生少量的CPU消耗以及磁盘IO，对其他客户端查询的性能影响较小。
• 对于插入操作引起的后台建索引行为也会严重影响查询操作，具体看后面一节。

（二）建索引操作对查询的影响

建索引有两种方式

a) 后台自动建索引, 主要的操作步骤是：

1. 调用create_collection建立一个空集合
2. 调用create_index给该集合指定一种索引（除IDMAP之外的任意一种索引）
3. 多次调用insert插入数据，每当累计插入数据量达到index_file_size设定的大小，后台就会自动给新增的index_file_size大小的数据块建立索引

b) 手动调用create_index建索引, 主要的操作步骤是：

1. 调用create_collection建立一个空集合
2. 多次调用insert插入数据，这时由于没有给集合指定索引，所以不会在后台自动建立索引
3. 手动调用create_index对整个集合的全部数据块建立索引，就算数据块的大小没有达到index_file_size设定的值，也会强制建索引，create_index是阻塞操作

分别在CPU和GPU两种模式下，两种建索引方式对查询的影响：

对于第1种方式：

• CPU版本：建索引和查询都需要全占CPU资源，因此在后台建索引的时候，查询任务会等待索引完成后才能执行。
• GPU版本：使用GPU建索引，其他的GPU或者CPU仍能执行查询任务，因此可以异步进行。

对于第2种方式：

• CPU版本：由于create_index是阻塞操作，同一个客户端上要等该操作完成后才能查询。如果使用多客户端，另一个客户端可以执行查询，但由于建索引和查询都需要全占CPU资源，因此在milvus在运行建索引的时候，查询任务会等待索引完成后才能执行。
• GPU版本：由于create_index是阻塞操作，同一个客户端上要等该操作完成后才能查询，建索引任务只使用一个GPU。如果使用多客户端，另一个客户端可以执行查询，使用其他的GPU或者CPU执行查询任务，因此可以异步进行。

（三）delete_by_id操作对查询的影响

• 该操作一般要连带调用flush以使得删除向量的操作生效，会产生少量的CPU消耗和磁盘IO，对其他客户端查询的性能影响较小

（四）compact操作对查询的影响

• delete_by_id操作只是记录了一个被删向量的id列表，并没有真正从数据文件里把向量数据删除，为了清理掉被删向量，需要调用compact操作。
• compact操作是很消耗资源的操作，其具体做的事情是：从原数据文件中提取出未被删除的向量数据，重新生成一份数据文件，如果该数据文件已经建好了索引，则把该索引文件删除，并重建一个新的索引文件。
• compact是阻塞操作，由于既有大量磁盘IO也可能连带有建索引的操作，因此会严重影响其他客户端的查询性能。

（五）获取信息的操作对查询的影响

• 获取信息的接口包括：describe_collection, describe_index, get_vector_ids, get_vector_by_id，collection_info等等。
• 这些接口都是从meta里获取信息返回客户端，或者读取某些记录向量信息的小文件，因此比较轻量，对其他客户端查询性能的影响很小。

（六）preload_collection操作对查询的影响

• preload_collection是把集合的数据预加载到缓存里，其功能相当于server_config.yaml里的preload_table这一项
• milvus启动时，如果没有预加载集合的数据，那么对这个集合的查询就要经过将数据从磁盘读入缓存这一阶段，对于大数据量的集合来说会非常慢，因此在查询之前调用preload_table可以把数据先加载进磁盘，虽然总的耗时不变，但对于希望第一次查询就有好性能的场合很适用。