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。

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