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的阈值，我觉得在小数据量的情况下操作有点杀鸡用牛刀，完全可以使用命令塞入数据的指定多个副本，做负载...个人观点仅供参考哈