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

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

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

。