如何快速查询milvus中int类型数据的最大最小值

[IeohMingChan]

请问在milvus中如何快速查询一个collection中某个int类型数据的最大最小值，经测试若遍历所有数据查找最值速度较慢，是否有更快的方式？谢谢

[xiaofan-luan]

应该是需要aggregation功能。
这个功能目前我们有代码但是目前还没进到trunk里

[IeohMingChan]

请问2.6版本大概在什么时候上线？

[xiaofan-luan]

预计这个月。这个发布可能还不会包含aggregation feature

[IeohMingChan]

目前我们在2.5.6版本中使用queryiterator遍历全部数据获得最值，由于数据量大目前效率非常差。由于临近上线deadline，请问基于这个版本是否有更快的办法获得最值，感谢

[xiaofan-luan]

大概有多少数据？获取min/max主要是什么场景？
我们可以考虑做一个beta版本，不过目前确实没有太多资源投入

[IeohMingChan]

谢谢大佬，我们目前不考虑使用beta版本，不必另外投入资源开发。
目前的使用场景是，使用int格式的名为seq_num的字段表示文档分片序列号。在插入自定义分片时，由于插入位置规定在最前面，需要首先获取当前文档分片的最小值以设定新自定义分片的序列号。
我们目前设置query_iterator的batch_size为1000，发现即使只有几条数据，单次检索时间也超过三秒钟。而使用query方法查询就快很多，但是query方法查询数量被限制在16384，query_iterator方法则没有限制但速度太慢。目前查询数据量取决于选定分区内指定文档的分片数，某些文档生成的分片数是大于16384的。请问对于目前query_iterator方法是否有参数或其他方面的优化建议，或者有没有更推荐使用的方案？

[yhmo]

也许有一个方法可以一试。
假设我有一张表，有个字段叫"flag"，int型，里面的值是未知的，值有可能很大有可能很小。
我给这个flag字段建了个索引。

schema = MilvusClient.create_schema()
schema.add_field(field_name="id", datatype=DataType.INT64, is_primary=True, auto_id=True)
schema.add_field(field_name="vector", datatype=DataType.FLOAT_VECTOR, dim=dim)
schema.add_field(field_name="flag", datatype=DataType.INT64)

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="vector",
    index_type="FLAT",
    metric_type="L2",
)
index_params.add_index(
    field_name="flag",
    index_type="STL_SORT",
)

client.create_collection(
    collection_name=collection_name,
    schema=schema,
    index_params=index_params,
)
print(collection_name, "created")

然后我用query这么检索，先检索flag > 0的，然后在返回的结果里取出flag最大值，作为下次query的条件。直到查不出任何结果了，就说明那个值是最大的。

max_value = 0
while True:
    filter = f"flag > {max_value}"
    print(f"query with '{filter}'")
    res = client.query(collection_name=collection_name,
                       filter=f"flag > {max_value}",
                       output_fields=["flag"],
                       limit=1000)
    if len(res) == 0:
        break
    for r in res:
        if r["flag"] > max_value:
            max_value = r["flag"]

print("max value = ", max_value)

注：如果flag字段里有大量重复值，比如超过1000个相同的值，这个query循环有可能会卡住，可以把limit放大点但不能超过16384

[yhmo]

返回的flag是乱序的，但只要你不是边插入数据边查询，基本上query几轮之后就能拿到最大值。
假设数据是固定的，没有新数据插入，每次查询得到的1000个flag虽然乱序，但是都比上一次的max_value大，因此你每次从results里拿到的最大值肯定比上次的大，有限次的query之后就能得到全局最大值。
一边插入数据一边query，就没法保证了，这种情况恐怕就只能等2.6版本的aggregation功能。

改maxQueryResultWindow只能对于百万级这种数据量有效，目的是能一次取出全部数据。但grpc传输有上限，最终你绕不过那个上限，对于几亿级别的数据你还是没法一次取出。

[phstan]

改maxQueryResultWindow是为了解决offset + limit限制不能超过16384，查询会加limit限制，每次只返回一部分数据，不会受传输上限影响吧

[xiaofan-luan]

这个解决不了问题，offset大或者limit大，都会导致单次返回的数据太多，会导致oom的

[phstan]

limit大OOM我理解，offset大是因为在Milvus Server这边遍历跳过offset会容易OOM吗

[yhmo]

从源码可以看到，offset这个事情是在proxy里做的。
proxy的searchTask的PostExecute()--> searchPostProcess() --> reduceResults() --> reduceSearchResult()

milvus/internal/proxy/task_search.go

Line 1051 in 44c0799

err = t.searchPostProcess(ctx, sp, toReduceResults)

milvus/internal/proxy/task_search.go

Line 811 in 44c0799

result, err := t.reduceResults(t.ctx, toReduceResults, t.SearchRequest.GetNq(), t.SearchRequest.GetTopk(), t.SearchRequest.GetOffset(), metricType, t.queryInfos[0], false)

https://github.com/milvus-io/milvus/blob/44c079933115531fdd419550847263b157bdf851/internal/proxy/task_search.go#L985C16-L985C35

milvus/internal/proxy/search_reduce_util.go

Line 23 in 44c0799

func reduceSearchResult(ctx context.Context, subSearchResultData []*schemapb.SearchResultData, reduceInfo *reduce.ResultInfo) (*milvuspb.SearchResults, error) {

所以，querynode会把limit数量的结果集传给proxy，然后由proxy来合并结果集再做offset。之所以这样做，是因为querynode有多个，它们各执有一部分结果集，谁也无法确定最终的结果，只能由proxy来做这个事情。
所以，limit越大，要传输的结果集越多，proxy的内存消耗越大。
永远不要不milvus server当成一个进程来理解，它是多个组件在运作。