Performance FAQ
How to set nlist
and nprobe
for IVF indexes?
Setting nlist
is scenario-specific. As a rule of thumb, the recommended value of nlist
is 4 × sqrt(n)
, where n
is the total number of entities in a segment.
The size of each segment is determined by the datacoord.segment.maxSize
parameter, which is set to 512 MB by default. The total number of entities in a segment n can be estimated by dividing datacoord.segment.maxSize
by the size of each entity.
Setting nprobe
is specific to the dataset and scenario, and involves a trade-off between accuracy and query performance. We recommend finding the ideal value through repeated experimentation.
The following charts are results from a test running on the sift50m dataset and IVF_SQ8 index, which compares recall and query performance of different nlist
/nprobe
pairs.
Accuracy test Performance test
Why do queries sometimes take longer on smaller datasets?
Query operations are conducted on segments. Indexes reduce the amount of time it takes to query a segment. If a segment has not been indexed, Milvus resorts to brute-force search on the raw data—drastically increasing query time.
Therefore, it usually takes longer to query on a small dataset (collection) because it has not built index. This is because the sizes of its segments have not reached the index-building threshold set by rootCoord.minSegmentSizeToEnableindex
. Call create_index()
to force Milvus to index segments that have reached the threshold but not yet been automatically indexed, significantly improving query performance.
What factors impact CPU usage?
CPU usage increases when Milvus is building indexes or running queries. In general, index building is CPU intensive except when using Annoy, which runs on a single thread.
When running queries, CPU usage is affected by nq
and nprobe
. When nq
and nprobe
are small, concurrency is low and CPU usage stays low.
Does simultaneously inserting data and searching impact query performance?
Insert operations are not CPU intensive. However, because new segments may not have reached the threshold for index building, Milvus resorts to brute-force search—significantly impacting query performance.
The rootcoord.minSegmentSizeToEnableIndex
parameter determines the index-building threshold for a segment, and is set to 1024 rows by default. See System Configuration for more information.
Can indexing a VARCHAR field improve deletion speed?
Indexing a VARCHAR field can speed up “Delete By Expression” operations, but only under certain conditions:
- INVERTED Index: This index helps for
IN
or==
expressions on non-primary key VARCHAR fields. - Trie Index: This index helps for prefix queries (e.g.,
LIKE prefix%
) on non-primary VARCHAR fields.
However, indexing a VARCHAR field does not speed up:
- Deleting by IDs: When the VARCHAR field is the primary key.
- Unrelated Expressions: When the VARCHAR field isn’t part of the delete expression.
Still have questions?
You can:
- Check out Milvus on GitHub. Feel free to ask questions, share ideas, and help others.
- Join our Slack Channel to find support and engage with our open-source community.