我们几乎将elasticsearch用作缓存，存储在时间窗口中找到的文档。我们不断插入许多不同大小的文档，然后使用结合日期过滤器的文本查询在ES中进行搜索，因此当前线程不会获取已经看到的文档。像这样：

“（（（word1 AND word 2）OR（word3 AND word4））AND insertDate> 1389000”

我们使用TTL功能在elasticsearch中将数据保留30分钟。如今，我们至少有3台机器每分钟每分钟插入大量新文件，并每隔一台机器不断地使用上述查询进行搜索。

我们在索引和检索这些文档方面遇到很多麻烦，我们没有获得由ES索引和返回的文档的大量吞吐量。每秒甚至无法索引200个文档。

我们认为问题在于同时进行查询，插入和TTL删除。我们不需要使旧数据保持弹性，我们只需要在给定时间以较小的时间窗对具有弹性索引的文档进行索引。我们应该怎么做才能提高绩效？

提前致谢

机型：

• Amazon EC2中型实例（3.7 GB RAM）

附加信息：

• 用于建立索引的代码是这样的：https : //gist.github.com/dggc/6523411

• 我们的elasticsearch.json配置文件：https : //gist.github.com/dggc/6523421

编辑

很抱歉给您提供一些反馈的时间过长。在我们公司，事情有点忙碌，我选择等待更平静的时期，以更详细地说明我们如何解决问题。我们仍然需要做一些基准测试来衡量实际的改进，但是重点是我们解决了这个问题:)

首先，我认为索引性能问题是由部分使用错误引起的。如前所述，我们将Elasticsearch用作一种缓存，用于在30分钟的时间范围内查找文档。我们在elasticsearch中寻找内容与某个查询匹配且插入日期在一定范围内的文档。然后，Elastic会返回完整的文档json（除索引内容外，还有大量数据）。我们的配置错误地（除了content和insertDate字段之外）错误地为文档json字段建立了索引，我们认为这是造成索引性能问题的主要原因。

但是，正如此处答案所建议的，我们还进行了许多修改，我们认为这些修改也改善了性能：

• 现在，我们不使用TTL功能，而是在通用别名下使用两个“滚动索引”。当索引变旧时，我们创建一个新索引，为其分配别名，然后删除旧索引。

• 我们的应用程序每秒执行大量查询。我们认为这会严重影响弹性，并降低索引性能（因为我们仅使用一个节点进行elasticsearch）。我们为该节点使用了10个分片，这导致我们向弹性触发的每个查询都转换为10个查询，每个分片一个。由于我们可以随时丢弃弹性数据（因此，改变分片数量对我们来说不是问题），因此我们只需将分片数量更改为1，就可以大大减少弹性节点中的查询数量。

• 我们的索引中有9个映射，每个查询都将触发到一个特定的映射。在这9个映射中，大约90％插入的文档进入了其中的两个映射。我们为每个映射创建了一个单独的滚动索引，并将其他7个映射保留在同一索引中。

• 并不是真正的修改，但是我们从Sematext安装了SPM（可扩展性能监视），这使我们可以密切监视elasticsearch并学习重要指标，例如，触发的查询数-> sematext.com/spm/index.html

我们的使用数量相对较小。我们大约有100个文档/秒到达，需要索引，峰值为400个文档/秒。至于搜索，我们每分钟大约有1500次搜索（更改分片数之前为15000）。在进行这些修改之前，我们遇到了那些性能问题，但现在还没有。