英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/retiring-data.html
本书基于 Elasticsearch 2.x 版本，有些内容可能已经过时。
数据过期 (Retiring Data)edit
随着时间推移，基于时间数据的相关度逐渐降低。 有可能我们会想要查看上周、上个月甚至上一年度发生了什么，但是大多数情况下，我们只对当前的感兴趣。
按时间范围索引的好处是可以方便地删除旧数据：只需要删除那些变得不重要的索引就可以了。
DELETE /logs_2013*
删除整个索引比删除单个文档要更加高效：Elasticsearch 只需要删除整个目录。
但是删除索引是 最后的决定 。在决定完全删除它之前，可以做一些让数据更加优雅地过期的事。
迁移旧索引 (Migrate Old Indices)edit
对日志数据来说，很有可能存在一个热点索引 —— 今日的索引。 所有新文档都会被添加到那个索引，几乎所有查询都以它为目标。那个索引应当使用你最好的硬件。
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)edit
昨日的索引不大可能会改变。 日志事件是静态的：过去发生的一切都只停留在过去。如果我们将每个分片合并至一个段(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 }
当然，没有副本，我们将面临磁盘灾难性故障而丢失数据的风险。你可能想要先通过snapshot-restore(快照恢复) API备份数据。
关闭旧索引 (Closing Old Indices)edit
当索引变得更“老”，它们到达一个几乎不会再被访问的时间点。 我们可以在这个阶段删除它们，但也许你想将它们留在这里以防万一有人在半年后还想要访问它们。
这些索引可以被关闭。它们还会存在于集群中，但它们不会消耗磁盘空间以外的资源。重新打开一个索引要比从备份中恢复快得多。
在关闭之前，值得我们去刷写(flush)索引来确保没有事务残留在事务日志中。一个空白的事务日志会使得索引在重新打开时恢复得更快：
归档旧索引 (Archiving Old Indices)edit
最后，非常旧的索引可以通过snapshot-restore API归档至长期存储例如共享磁盘或者 Amazon S3，以防日后你可能需要访问它们。
一旦备份完成，我们就可以将索引从集群中删除了。