ElasticSearch - 高索引吞吐量

Question

我正在对ElasticSearch进行基准测试,以实现非常高的索引吞吐量目的.

我目前的目标是能够在几小时内索引30亿(3,000,000,000)个文档.为此,我目前有3台Windows服务器机器,每台机器有16GB RAM和8个处理器.正在插入的文档具有非常简单的映射,仅包含少数非分析的数字字段(_all已禁用).

我能够使用这个相对适中的装备每秒达到大约120,000个索引请求(使用大桌面进行监控),我相信可以进一步提高吞吐量.我正在使用一些.net NEST客户端来发送索引批量请求,批量处理1500个索引操作.

不幸的是,每秒120k请求的吞吐量不会持续很长时间,并且速率逐渐降低,在几个小时后降至~15k.

监控机器显示cpu不是瓶颈.但是,所有机器上的物理磁盘(而不是SSD)空闲时间似乎都在下降,平均闲置率低于15%.

设置refresh_interval为60s,而不是300s,最后是15m,似乎没什么帮助.在单个分片中监视单个translog,显示translog每30分钟刷新一次,然后达到200MB.

我尝试过使用两种分片策略:

1. 1个索引,有60个分片(没有副本).
2. 3个索引,每个20个分片(没有副本).

这两种尝试都会产生相当类似的体验,我认为这是有意义的,因为它是相同数量的分片.

看一下这些片段,我可以看到大多数分片都有~30个已提交的片段,以及相似数量的可搜索片段.细分市场规模各不相同 有一段时间,尝试使用max_num_segments = 1来优化索引,在完成之后似乎有所帮助(花了很长时间).

在任何时候,从一开始就开始整个摄取过程,在删除使用过的索引并创建新索引之后 - 导致相同的行为.最初的高指数吞吐量,但逐渐减少,早在达到30亿文件的目标之前.此时的索引大小约为120GB.

我正在使用ElasticSearch 1.4版本.Xms和Xmx配置为8192MB,可用内存的50%.索引缓冲区设置为30%.

我的问题如下:

1. 假设磁盘目前是这个装备的瓶颈,这种逐渐增加磁盘利用率的现象是正常的吗？如果没有,可以做些什么来否定这些影响呢？
2. 我是否可以通过微调来提高索引吞吐量？我是不是该？或者我应该向外扩展.

Answer 1

长话短说,我最终得到了5个虚拟linux机器,8个cpu,16 GB,使用puppet来部署elasticsearch.我的文件变得更大了,但是吞吐率(稍微)也是如此.我平均能够达到150K索引请求/秒,在2小时内索引10亿个文档.吞吐量不是恒定的,我观察到与以前类似的吞吐量行为减少,但程度较小.由于我将使用相同数量的每日索引,我希望这些性能指标每天大致相似.

从Windows机器到Linux的过渡主要是由于方便和符合IT惯例.虽然我不确定,我怀疑在Windows上也可以实现相同的结果.

在我的几个试验中,我尝试索引而不指定文档ID,正如Christian Dahlqvist建议的那样.结果令人惊讶.我观察到吞吐量显着增加,在某些情况下达到300k甚至更高.结论很明显:除非您必须,否则不要指定文档ID.

此外,我每台机器使用更少的分片,这也有助于提高吞吐量.