You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: site/en/userGuide/search-query-get/filtered-search.md
+193-2Lines changed: 193 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,10 @@ An ANN search finds vector embeddings most similar to specified vector embedding
11
11
12
12
## Overview
13
13
14
+
In Milvus, filtered searches are categorized into two types — **standard filtering** and **iterative filtering** — depending on the stage at which the filtering is applied.
15
+
16
+
## Standard Filtering
17
+
14
18
If a collection contains both vector embeddings and their metadata, you can filter metadata before ANN search to improve the relevancy of the search result. Once Milvus receives a search request carrying a filtering condition, it restricts the search scope within the entities matching the specified filtering condition.
@@ -23,6 +27,18 @@ As shown in the above diagram, the search request carries `chunk like % red %` a
23
27
24
28
- Returns top-K entities.
25
29
30
+
## Iterative Filtering
31
+
32
+
The standard filtering process effectively narrows the search scope to a small range. However, overly complex filtering expressions may result in very high search latency. In such cases, iterative filtering can serve as an alternative, helping to reduce the workload of scalar filtering.
As illustrated in the diagram above, a search with iterative filtering performs the vector search in iterations. Each entity returned by the iterator undergoes scalar filtering, and this process continues until the specified topK results are achieved.
37
+
38
+
This method significantly reduces the number of entities subjected to scalar filtering, making it especially beneficial for handling highly complex filtering expressions.
39
+
40
+
However, it’s important to note that the iterator processes entities one at a time. This sequential approach can lead to longer processing times or potential performance issues, especially when a large number of entities are subjected to scalar filtering.
41
+
26
42
## Examples
27
43
28
44
This section demonstrates how to conduct a filtered search. Code snippets in this section assume you already have the following entities in your collection. Each entity has four fields, namely **id**, **vector**, **color**, and **likes**.
@@ -43,7 +59,9 @@ This section demonstrates how to conduct a filtered search. Code snippets in thi
43
59
44
60
```
45
61
46
-
The search request in the following code snippet carries a filtering condition and several output fields.
62
+
### Search with Standard Filtering
63
+
64
+
The following code snippets demonstrate a search with standard filtering, and the request in the following code snippet carries a filtering condition and several output fields.
47
65
48
66
<divclass="multipleCode">
49
67
<a href="#python">Python </a>
@@ -235,4 +253,177 @@ The filtering condition carried in the search request reads `color like "red%" a
235
253
236
254
```
237
255
238
-
For more information on the operators that you can use in metadata filtering, refer to [Metadata Filtering](boolean.md).
256
+
For more information on the operators that you can use in metadata filtering, refer to [Metadata Filtering](boolean.md).
257
+
### Search with iteraive filtering
258
+
259
+
To conduct a filtered search with iterative filtering, you can do as follows:
export filter='partition_key in ["x", "y", "z"] && <other conditions>'
260
260
261
261
```
262
+
263
+
<divclass="alert note">
264
+
265
+
You have to replace `partition_key` with the name of the field that is designated as the partition key.
266
+
267
+
</div>
268
+
269
+
## Use Partition Key Isolation
270
+
271
+
In the multi-tenancy scenario, you can designate the scalar field related to tenant identities as the partition key and create a filter based on a specific value in this scalar field. To further improve search performance in similar scenarios, Milvus introduces the Partition Key Isolation feature.
As shown in the above figure, Milvus groups entities based on the Partition Key value and creates a separate index for each of these groups. Upon receiving a search request, Milvus locates the index based on the Partition Key value specified in the filtering condition and restricts the search scope within the entities included in the index, thus avoiding scanning irrelevant entities during the search and greatly enhancing the search performance.
276
+
Once you have enabled Partition Key Isolation, you can include only a specific value in the Partition-key-based filter so that Milvus can restrict the search scope within the entities included in the index that match.
277
+
278
+
<divclass="alert note">
279
+
280
+
Currently, the Partition-Key Isolation feature applies only to searches with the index type set to HNSW.
281
+
282
+
</div>
283
+
284
+
### Enable Partition Key Isolation
285
+
286
+
The following code examples demonstrate how to enable Partition Key Isolation.
Once you have enabled Partition Key Isolation, you can still set the Partition Key and number of partitions as described in [Set Partition Numbers](#Set-Partition-Numbers). Note that the Partition-Key-based filter should include only a specific Partition Key value.
0 commit comments