我正在对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。
我尝试过使用两种分片策略：
这两种尝试都会产生相当类似的体验，我认为这是有道理的，因为它的碎片数量相同。
查看细分，我可以看到大多数分片都有~30个已提交的片段，以及相似数量的可搜索片段。细分市场规模各不相同有一段时间，尝试使用max_num_segments = 1来优化索引，在完成之后似乎有所帮助（花了很长时间）。
在任何时候，在删除使用过的索引并创建新索引之后，从头开始整个摄取过程会产生相同的行为。最初的高指数吞吐量，但逐渐减少，早在达到30亿文件的目标之前。该时间的索引大小约为120GB。
我正在使用ElasticSearch 1.4版本。 Xms和Xmx配置为8192MB，可用内存的50％。索引缓冲区设置为30％。
我的问题如下：
答案 0 :(得分：37)
长话短说，我最终得到了5个虚拟linux机器，8个cpu，16 GB，使用puppet来部署elasticsearch。 我的文件变得更大了，但是吞吐率（稍微）也是如此。 我平均能够达到150K索引请求/秒，在2小时内索引10亿个文档。 吞吐量不是恒定的，我观察到与以前类似的吞吐量行为减少，但程度较小。由于我将使用每日索引来获取相同数量的数据，因此我希望这些性能指标每天大致相似。
从Windows机器到Linux的过渡主要是由于方便和符合IT惯例。虽然我不确定，但我怀疑在Windows上也可以获得相同的结果。
在我的几个试验中，我尝试索引而不指定文档ID，正如Christian Dahlqvist建议的那样。结果令人惊讶。我观察到 显着的 吞吐量增加，在某些情况下达到300k及更高。结论很明显：除非你绝对必须，否则不要指定文档ID。
此外，我每台机器使用较少的分片，这也有助于提高吞吐量。