如果您要处理时间序列数据，则不想将所有内容连续转储到单个索引中。 取而代之的是，您可以定期将数据滚动到新索引，以防止数据过大而又缓慢又昂贵。 随着索引的老化和查询频率的降低，您可能会将其转移到价格较低的硬件上，并减少分片和副本的数量。
要在索引的生命周期内自动移动索引，可以创建策略来定义随着索引的老化对索引执行的操作。 索引生命周期策略在与Beats数据发件人一起使用时特别有用，Beats数据发件人不断将运营数据（例如指标和日志）发送到Elasticsearch。 当现有索引达到指定的大小或期限时，您可以自动滚动到新索引。 这样可以确保所有索引具有相似的大小，而不是每日索引，其大小可以根beats数和发送的事件数而有所不同。
让我们通过动手操作场景跳入索引生命周期管理（Index cycle management: ILM）。 本文章将利用您可能不熟悉的ILM独有的许多新概念。 我们先用一个示例来展示。本示例的目标是建立一组索引，这些索引将封装来自时间序列数据源的数据。 我们可以想象有一个像Filebeat这样的系统，可以将文档连续索引到我们的书写索引中。 我们希望在索引达到50 GB，或文档的数量超过10000，或已在30天前创建索引后对其进行rollover，然后在90天后删除该索引。
详细阅读，请参阅https://blog.csdn.net/UbuntuTo ... 28987
更多Elastic学习资料：https://blog.csdn.net/ubuntutouch
要在索引的生命周期内自动移动索引，可以创建策略来定义随着索引的老化对索引执行的操作。 索引生命周期策略在与Beats数据发件人一起使用时特别有用，Beats数据发件人不断将运营数据（例如指标和日志）发送到Elasticsearch。 当现有索引达到指定的大小或期限时，您可以自动滚动到新索引。 这样可以确保所有索引具有相似的大小，而不是每日索引，其大小可以根beats数和发送的事件数而有所不同。
让我们通过动手操作场景跳入索引生命周期管理（Index cycle management: ILM）。 本文章将利用您可能不熟悉的ILM独有的许多新概念。 我们先用一个示例来展示。本示例的目标是建立一组索引，这些索引将封装来自时间序列数据源的数据。 我们可以想象有一个像Filebeat这样的系统，可以将文档连续索引到我们的书写索引中。 我们希望在索引达到50 GB，或文档的数量超过10000，或已在30天前创建索引后对其进行rollover，然后在90天后删除该索引。
详细阅读，请参阅https://blog.csdn.net/UbuntuTo ... 28987
更多Elastic学习资料：https://blog.csdn.net/ubuntutouch
0 个回复