milvus 查询时的原理
当读取数据时,MsgStream对象在以下场景中创建:
在 Milvus 中,数据必须先加载后才能读取。当代理收到数据加载请求时,会将请求发送给查询协调器,查询协调器决定如何将分片分配到不同的查询节点。分配信息(即 vchannels 的名称以及 vchannels 与其对应的 pchannels 之间的映射)通过方法调用或 RPC(远程过程调用)发送给查询节点。随后,查询节点会创建相应的 MsgStream 对象来消费数据。
问题的解决:
https://github.com/milvus-io/milvus/discussions/32698
具体为什么会产生这个问题,可以看我上一篇文章
https://blog.csdn.net/IT_Octopus/article/details/141605964?spm=1001.2014.3001.5501
考虑到大家网络可能不好截图出来:
其中大致的内容都看懂了,比较困难的是
大致上是每个collection有一根数据管道,其中有一个querynode负责管理这根管道,我们称之为shard-leader,它从管道中接收来自pulsar的数据,数据积累在内存里,称为growing segment,当数据达到一定量,比如一百兆,就把这块数据落盘变成sealed segment,其他的querynode等加载sealed segment。
你插入的数据太少,大部分都在growing segment里,所以数据都在shard-leader里。如果你插入10GB的数据,你会发现其他的querynode也开始有数据。
看起来,你们应该有比较多的partition,每个partition都会有growing数据,而growing数据都会在shard delegator上。默认情况下只有一个delegator,因此大部分数据都在一台机器上。
2. 调小segment flush的阈值,使得数据更快flush,growing的数据更少。
这几句话,我个人理解一下哈:
动态的数据:
1.数据量太小,且数据是动态新增的,且没有60s间隔,没有达到segement分区的限制,没有从growingSegement态变成sealed态,所以都落在其中的一个segement。所以没有触发querynode分配。
数据插入和 Growing Segment: 当新数据被插入 Milvus 时,它们首先被写入 Growing Segment。Growing Segment 是一个可以继续接收新数据的活跃段。
Flush 操作和 Sealed Segment: Flush 操作会将 Growing Segment 中的数据持久化到存储中,并将 Growing Segment 转变为 Sealed Segment。Sealed Segment 是一个已关闭的段,不能再接收新的数据插入。3. Flush 阈值: Milvus 有一个阈值来决定何时自动执行 Flush 操作(60s)。这个阈值通常基于数据量或时间间隔
静态数据 or 封闭数据
"以分片为单位做balance" 这句话是我理解这个问题的核心点,
意思只有到达某个阈值的时候才会开启分配到其他queynode节点
通过上述搜索原理 和 官方回答的讨论可以得到这个结论
1.数据量不够,没有达到querynode 一个资源的限额。
2.在数据量小的情况下,少querynode ,每个querynode 多资源
3.调整flush的阈值,我觉得在小数据量的情况下操作有点杀鸡用牛刀,完全可以使用命令塞入数据的指定多个副本,做负载...个人观点仅供参考哈