数据过期

数据过期

随着时间推移，基于时间数据的相关度逐渐降低。有可能我们会想要查看上周、上个月甚至上一年度发生了什么，但是大多数情况，我们只关心当前发生的。

按时间范围索引带来的一个好处是可以方便地删除旧数据：只需要删除那些变得不重要的索引就可以了。

DELETE /logs_2013*

删除整个索引比删除单个文档要更加高效：Elasticsearch 只需要删除整个文件夹。

但是删除索引是 终极手段 。在我们决定完全删除它之前还有一些事情可以做来帮助数据更加优雅地过期。

迁移旧索引

随着数据被记录，很有可能存在一个热点索引——今日的索引。所有新文档都会被加到那个索引，几乎所有查询都以它为目标。那个索引应当使用你最好的硬件。

Elasticsearch 是如何得知哪台是你最好的服务器呢？你可以通过给每台服务器指定任意的标签来告诉它。例如，你可以像这样启动一个节点：

    ./bin/elasticsearch --node.box_type strong

box_type 参数是完全随意的——你可以将它随意命名只要你喜欢——但你可以用这些任意的值来告诉 Elasticsearch 将一个索引分配至何处。

我们可以通过按以下配置创建今日的索引来确保它被分配到我们最好的服务器上：

PUT /logs_2014-10-01
{
  "settings": {
    "index.routing.allocation.include.box_type" : "strong"
  }
}

昨日的索引不再需要我们最好的服务器了，我们可以通过更新索引设置将它移动到标记为 medium 的节点上：

POST /logs_2014-09-30/_settings
{
  "index.routing.allocation.include.box_type" : "medium"
}

索引优化（Optimize）

昨日的索引不大可能会改变。(((“indices”, “optimizing”))) 日志事件是静态的：已经发生的过往不会再改变了。如果我们将每个分片合并至一个段（Segment），它会占用更少的资源更快地响应查询。我们可以通过optimize-api来做到。

对还分配在 strong 主机上的索引进行优化（Optimize）操作将会是一个糟糕的想法，因为优化操作将消耗节点上大量 I/O 并对索引今日日志造成冲击。但是 medium 的节点没有做太多类似的工作，我们可以安全地在上面进行优化。

昨日的索引有可能拥有副本分片。如果我们下发一个优化（Optimize）请求，它会优化主分片和副本分片，这有些浪费。然而，我们可以临时移除副本分片，进行优化，然后再恢复副本分片：

POST /logs_2014-09-30/_settings
{ "number_of_replicas": 0 }
POST /logs_2014-09-30/_optimize?max_num_segments=1
POST /logs_2014-09-30/_settings
{ "number_of_replicas": 1 }

当然，没有副本我们将面临磁盘故障而导致丢失数据的风险。你可能想要先通过{ref}/modules-snapshots.html[snapshot-restore API]备份数据。

关闭旧索引

当索引变得更“老”，它们到达一个几乎不会再被访问的时间点。我们可以在这个阶段删除它们，但也许你想将它们留在这里以防万一有人在半年后还想要访问它们。

这些索引可以被关闭。它们还会存在于集群中，但它们不会消耗磁盘空间以外的资源。重新打开一个索引要比从备份中恢复快得多。

在关闭之前，值得我们去刷写索引来确保没有事务残留在事务日志中。一个空白的事务日志会使得索引在重新打开时恢复得更快：

POST /logs_2014-01-*/_flush (1)
POST /logs_2014-01-*/_close (2)
POST /logs_2014-01-*/_open (3)

<1> 刷写（Flush）所有一月的索引来清空事务日志。

<2> 关闭所有一月的索引.

<3> 当你需要再次访问它们时，使用 open API 来重新打开它们。

归档旧索引

最后，非常旧的索引可以通过{ref}/modules-snapshots.html[snapshot-restore API]归档至长期存储例如共享磁盘或者 Amazon S3，以防日后你可能需要访问它们。当存在备份时我们就可以将索引从集群中删除了。