ElasticSearch-高索引吞吐量

Question

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

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

使用这个相对适中的钻机，我能够达到每秒大约120,000个索引请求（使用大桌子监控），我相信吞吐量可以进一步提高。我使用了许多. net NEST客户端来发送索引批量请求，其中1500个索引操作是批量的。

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

监控机器表明cpu不是瓶颈。然而，所有机器上的物理磁盘（而不是SSD）空闲时间似乎都在下降，平均空闲时间不到15%。

将refresh_interval设置为60，而不是300，最后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。我的文件变大了一点，但是丢弃率也变大了（稍微）。我平均每秒能够达到15万个索引请求，在2小时内索引10亿个文档。吞吐量不是恒定的，我观察到了与之前类似的吞吐量递减行为，但程度较低。由于我将对相同数量的数据使用每日指数，因此我希望这些性能指标每天大致相似。

从windows机器到linux的过渡主要是因为方便和遵守IT惯例。虽然我不确定，但我怀疑同样的结果也可以在windows上实现。

在我的几次试验中，我试图按照克里斯蒂安·达尔奎斯特的建议，在没有指定文档id的情况下编制索引。结果是惊人的。我观察到吞吐量显著增加，在某些情况下达到300k甚至更高。结论是显而易见的：除非万不得已，否则不要指定文档ID。

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