performance - 使用Elasticsearch作为时间窗口存储的性能问题

Question

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

“(((word1 AND word 2)OR(word3 AND word4))AND insertDate> 1389000”

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

我们在索引和检索这些文档时遇到很多麻烦，而ES索引和返回的文档吞吐量却不高。每秒甚至无法索引200个文档。

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

提前致谢

机型:

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功能，而是在通用别名下使用两个“滚动索引”。当索引变旧时，我们创建一个新索引，为其分配别名，然后删除旧索引。

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

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

并不是真正的修改，但是我们从Sematext安装了SPM(可扩展性能监视)，它使我们能够密切监视 flex 搜索并学习重要指标，例如触发的查询数-> sematext.com/spm/index.html

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

Answer 1

TTL到基于时间序列的索引

您应该考虑使用基于时间序列的索引，而不是TTL功能。假设您只关心文档的最近30分钟窗口，请使用基于日期/时间的命名约定为每30分钟创建一个新索引: docs-201309120000，docs-201309120030，docs-201309120100，docs-201309120130等(请注意命名惯例中30分钟的增量。)

使用Elasticsearch的索引别名功能(http://www.elasticsearch.org/guide/reference/api/admin-indices-aliases/)，您可以将docs别名为最近创建的索引，以便在进行批量索引时，始终使用别名docs，但是它们会被写入docs-201309120130中。

查询时，您将过滤日期时间字段以确保仅返回最近30分钟的文档，并且您需要查询2个最近创建的索引以确保获得完整的30分钟的文档-您可以在这里创建另一个别名以指向两个索引，或者直接查询两个索引名称。

使用此模型，您没有使用TTL的开销，并且仅可以删除过去一个多小时内未使用的旧索引。

还有其他方法也可以提高批量索引和查询速度，但是我认为删除TTL将是最大的胜利-另外，您的索引仅具有有限的数据量以供筛选/查询，这应该提供一个不错的选择提速。

Elasticsearch设置(例如内存等)

这是我通常针对运行ES的服务器调整的一些设置-http://pastebin.com/mNUGQCLY，请注意，它仅适用于1GB VPS，因此需要进行调整。

节点角色

研究主数据，数据和“客户端” ES节点类型也可能对您有所帮助-http://www.elasticsearch.org/guide/reference/modules/node/

索引设置

进行批量插入时，请考虑同时修改index.refresh_interval和index.merge.policy.merge_factor的值-我看到您已将refresh_interval修改为5s，但考虑在批量索引操作之前将其设置为-1，然后返回所需的时间间隔。或者，考虑在批量操作完成后手动执行_refresh API手动命中，特别是如果您每分钟只进行批量插入-在这种情况下，这是受控环境。

使用index.merge.policy.merge_factor，将其设置为更高的值可减少ES在后台执行的段合并数量，然后在批量操作恢复正常行为后恢复为默认值。通常建议为批量插入设置30，默认值为10。