按照Logstash Elasticsearch input plugin的描述,它会使用scroll API获取源端的数据
而根据Elasticsearch scroll相关的文档说明,一个scroll请求的数据肯定来自于同一个shard(我应该没理解错吧?)
那么如果使用Logstash从ES导入到ES,并且保留源端的_id的话,就会出现在某一个时间段中大量的请求全部发送到同一个节点的情况(假设源端和目标端的shard数配置成一样)。
那这样不是必然会出现目标端的节点的在导入过程中资源使用不均衡吗?
在某一个时间段,几乎所有的document都是routing到同一个节点。
我理解的有问题么?
如果没有问题,那这种情况Logstash是怎么考虑的呢?
scroll
Value type is string
Default value is "1m"
This parameter controls the keepalive time in seconds of the scrolling request and initiates the scrolling process. The timeout applies per round trip (i.e. between the previous scroll request, to the next).
而根据Elasticsearch scroll相关的文档说明,一个scroll请求的数据肯定来自于同一个shard(我应该没理解错吧?)
By default the splitting is done on the shards first and then locally on each shard using the _uid field with the following formula: slice(doc) = floorMod(hashCode(doc._uid), max) For instance if the number of shards is equal to 2 and the user requested 4 slices then the slices 0 and 2 are assigned to the first shard and the slices 1 and 3 are assigned to the second shard.
那么如果使用Logstash从ES导入到ES,并且保留源端的_id的话,就会出现在某一个时间段中大量的请求全部发送到同一个节点的情况(假设源端和目标端的shard数配置成一样)。
那这样不是必然会出现目标端的节点的在导入过程中资源使用不均衡吗?
在某一个时间段,几乎所有的document都是routing到同一个节点。
我理解的有问题么?
如果没有问题,那这种情况Logstash是怎么考虑的呢?
1 个回复
bellengao - 博客: https://www.jianshu.com/u/e0088e3e2127
赞同来自: