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

[FiveTreesHigh]

好的，非常感谢！

[renyuanming]

您好，你这里提到了shard-leader，请问这个shard-leader是怎么设置的？这个shard-leader是负责整个collection update的数据的吗？shard-leader可以动态变化吗？因为如果collection比较大的话，只选择一个query node做leader可能成为比较大的bottleneck.

[yhmo]

每个collection的每个shard都会对应一个shard-leader
每个shard-leader由一个query node承担，多个shard-leader可存在于同一个query node上
insert/upsert的数据都会先进入pulsar/kakfa，然后由shard-leader负责接收，shard-leader只接收它所对应的shard的数据，数据累积在growing segment中。datanode也会有对应节点消费shard的数据。datanode和query node shard-leader所消费的数据会同步，也就是说，growing segment的数据在shard-leader里有一份，在datanode里也有一份，当datanode消费的数据达到一定量时，会把该growing segment持久化为sealed segment，然后同时shard-leader也会得到通知，把这个growing segment标记为sealed
shard-leader加载的数据量会相应小一些，以减少它的压力，但在某些场景下仍可能成为瓶颈，比如连续密集写入数据时，大量growing segment会累积在shard-leader形成瓶颈。

[renyuanming]

意思是说同一个 query node上会存属于多个shard的数据？那同一个query node上的不同shard各自都是一个完整的shard，还是一个shard的数据也可能会分散到多个query node上？另外shard-leader是如何指定的呢？谢谢！

[yhmo]

是的同一个querynode有可能存在多个shard-leader。对于standalone的milvus来说，只有一个querynode，所以，全部shard leader都在同一个querynode上。
每一个shard，有两种数据，一种是sealed segment的数据，另一种是growing segment的数据。sealed segment的数据可以分发给其他query node。growing segment的数据只能存在于shard leader上。
shard-leader的指定应该没什么复杂逻辑，大致就是两个标准，shard数量均匀，然后数据量均匀。要看细节的话只能去翻代码。

[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个吧。

[xiaofan-luan]

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

如果是有频繁写入的，delegator节点内存确实会高于其他节点。因为出了存量数据，他上面还有增量数据。有几个G是符合预期的。

1. 调低growing segment的大小。默认的growing segment大概是100多MB一个，如果你有32个或者64个partition，那么就会包括几个G的growing数据。调低到几十MB是可行的，但不要太小。把sealProportion 从0.12调整到0.04是可以的。
2. 减少节点个数，与其用8个8GB的节点，不如用4个16GB的节点，不均匀程度就减少了。
3. 调整balance算法，不在delegator上加载其他sealed segment数据。不推荐这么做。

[Niceies]

如果querynode shard-leader里面存储了增长的信息，那么querynode在进行查询的时候是否不会去pulsar查询。直接在内存中的growing segment进行查询然后返回结果。并且根据设置数据一致性来判断在查询growing segment中的时间段和等待growing segment从pulsar来的数据？

[yhmo]

insert/upsert/delete的数据会进去pulsar的消息流里，各个querynode不断地从pular中拉取数据，拉取到11点20分的数据就认为该querynode的数据同步到了11点20分这个点位。也许有的querynode同步到11点20分，有的querynode同步到11点21分。当11点21分有一个sarch请求进来，如果consistency level=STRONG那么由于有的querynode还未同步到11点21分，这个请求就等着，等到所有querynode都同步到11点21分之后才开始执行这个search。此时，各个querynode上的growing segment都已同步到11点21分这个位置。