ElasticSearch -高索引吞吐量

Question

为了达到非常高的索引吞吐量目的，我正在对ElasticSearch进行基准测试。

我目前的目标是能够在几个小时内索引30亿(30亿)个文档。为此，我目前有3台windows服务器机器，每台有16 and和8个处理器。插入的文档具有非常简单的映射，只包含少数数值非分析字段(禁用了_all)。

我能够达到大约12万个索引请求每秒(使用大办公桌进行监视)，使用这个相对较小的平台，我相信吞吐量可以进一步提高。我使用了许多.net NEST客户端来发送索引批量请求，其中有1500个索引操作。

不幸的是，每秒120 k请求的吞吐量不会持续很长时间，而且速率会逐渐下降，几个小时后下降到~15k。

监视机器显示cpu不是瓶颈。然而，物理磁盘(而不是SSD)空闲时间似乎在所有机器上下降，平均空闲时间不到15%。

将refresh_interval设置为60，而不是300，最后是1500万，似乎没有多大帮助。在一个碎片中监视一个translog，显示translog每30分钟刷新一次，直到达到200 on。

我尝试过使用两种切分策略：

1. 一个索引，有60个碎片(没有副本)。
2. 3个索引，每个索引有20个碎片(没有副本)。

这两次尝试都产生了相当相似的体验，我想这是有意义的，因为碎片的数量是一样的。

查看这些段，我可以看到大多数碎片都有~30个已提交的段，以及相同数量的可搜索段。分段大小各不相同。有一次，用max_num_segments=1优化索引的尝试在它完成后似乎得到了一点帮助(花了很长时间)。

在任何时候，在删除使用的索引并创建新的索引之后，从一开始就开始整个摄入过程--结果是相同的行为。最初，索引吞吐量很高，但逐渐减少，很久之后才达到30亿个文档的目标。当时的索引大小约为120 is。

我使用的是ElasticSearch 1.4版本。Xms和Xmx配置为8192 Xmx，占可用内存的50%。索引缓冲区设置为30%。

我的问题如下：

1. 假设磁盘目前是这个平台的瓶颈，这种逐渐增加磁盘利用率的现象是否是正常现象？如果没有，怎样才能消除这些影响呢？
2. 有什么微调可以提高索引吞吐量吗？我应该吗？或者我应该扩大规模。

Answer 1

长话短说，我最终得到了5台虚拟linux机器，8 cpu，16 GB，使用傀儡部署elasticsearch。我的文档变大了一点，但通过率(略)也是如此。我平均能够达到150 K索引请求/秒，在2小时内为10亿个文档建立索引。吞吐量不是常数，我观察到类似的吞吐量递减行为，但程度较小。由于我将对相同数量的数据使用每日索引，所以我预计这些性能指标每天都会大致相似。

从windows机器到linux的转换主要是由于方便和遵守IT约定。虽然我不确定，但我怀疑同样的结果也可以在windows上实现。

在我的几次试验中，我尝试索引时没有指定文档ids，就像Christian Dahlqvist建议的那样。结果令人震惊。我观察到显著增加了吞吐量，在某些情况下达到300 K甚至更高。这一点的结论是显而易见的:除非绝对必须指定文档ids，否则不要指定文档ids。

另外，我每台机器都使用较少的碎片，这也有助于提高吞吐量。