Query node加载数据原理

[yangyingchun1994]

目前我们QueryNode有10个节点，发现一个现象是加载某一个colection数据到query时，只有某个querynode的内存出现了比较大的增加：0.8G ->0.89G
0.76 ->5.51
0.71 ->0.80
0.70 ->0.74
0.65 ->0.68
0.69 ->0.71
0.89 ->0.94
0.89 ->0.99
0.74 ->0.77
0.79 ->0.79而其他节点变化很小，咨询一下 collection的数据是只会加载到某一个queryNode中吗，具体的工作原理是什么

[yhmo]

大致上是每个collection有一根数据管道，其中有一个querynode负责管理这根管道，我们称之为shard-leader，它从管道中接收来自pulsar的数据，数据积累在内存里，称为growing segment，当数据达到一定量，比如一百兆，就把这块数据落盘变成sealed segment，其他的querynode等加载sealed segment。
你插入的数据太少，大部分都在growing segment里，所以数据都在shard-leader里。如果你插入10GB的数据，你会发现其他的querynode也开始有数据。

Read this doc to learn more: https://milvus.io/blog/deep-dive-3-data-processing.md

[yangyingchun1994]

那如果我一个collection的数量非常庞大，加载数据会分别加载到不同的querynode中吗

[yhmo]

会的。
数据都是分片管理，分片就是segment。一个collection有很多分片，分片的大小一般从一百兆到几百兆不等。数据多了，一个collection里就有几十上百个分片，以分片为单位做balance

[yangyingchun1994]

In Milvus, data cannot be read unless they are loaded. When the proxy receives a data load request, it sends the request to query coordinator which decides the way of assigning shards to different query nodes. The assigning information (i.e. The names of vchannels and the mapping between vchannels and their corresponding pchannels) is sent to query nodes via method call or RPC (remote procedure call). Subsequently, the query nodes create corresponding MsgStream objects to consume data.

根据这我理解一个collection数据是可以加载到不同的 querynode中的，上述您说了插入10个G数据后会发现其他也有数据，这个10个G是milvus内置的1个参数吗 还是一个经验值；这个load到querynode的过程会是 banlance的吗

[xiaofan-luan]

目前我们QueryNode有10个节点，发现一个现象是加载某一个colection数据到query时，只有某个querynode的内存出现了比较大的增加：0.8G ->0.89G 0.76 ->5.51 0.71 ->0.80 0.70 ->0.74 0.65 ->0.68 0.69 ->0.71 0.89 ->0.94 0.89 ->0.99 0.74 ->0.77 0.79 ->0.79而其他节点变化很小，咨询一下 collection的数据是只会加载到某一个queryNode中吗，具体的工作原理是什么

看起来，你们应该有比较多的partition，每个partition都会有growing数据，而growing数据都会在shard delegator上。默认情况下只有一个delegator，因此大部分数据都在一台机器上。
建议： 1. 用更少的机器，比如看起来你们数据很少，可能只需要2-3台更大规格的querynode
2. 调小segment flush的阈值，使得数据更快flush，growing的数据更少。

[vivawz]

我也遇到类似的问题。请教下，怎么修改 delegator 的数量。
对于建议1， 当流量较大时，并不能无限提供高规格的 querynode
2. 试了试，效果不明显

[yhmo]

当你建表的时候如果指定num_shards=4，就相应会有4个delegator
hello_milvus = Collection("hello_milvus", schema, num_shards = 4)

根据数据的primary key流到不同的delegator里，然后delegator再分发给其他work query node。一般几百万数据集用1个shard就可以，几千万用2个，数亿就开4个吧。