09-Retiring Data-关闭旧数据（time-based）

Retiring Data

在time-based中，数据关联性很小，maybe我们只关心我们现在的数据。最近3天 1周 1个月。。。

你可以选择的办法是直接删除掉旧的index。。。

DELETE /logs_2013*

删除整个index会比删除一条条doc快很多也爽很多，但明显SB才这样做。。。

所以下面的办法才是官方建议的

migrate old indices 转移旧index

对于log data 总有index是hot index，而旧数据的index是很少访问的，所以新的数据应该指向new index，而且大部分的查询应该指向该index，而且这个node应该配置不错。

然而es咋知道哪个服务器是最好的服务器呢，你可以通过设置告诉系统，在启动节点的时候你可以通过配置强制告诉系统

./bin/elasticsearch --node.box_type strong

还可以对index进行设置

PUT /logs_2014-10-01

{

  "settings": {

    "index.routing.allocation.include.box_type" : "strong"

  }

}

POST /logs_2014-09-30/_settings

{

  "index.routing.allocation.include.box_type" : "medium"

}

optimize

以前的数据是很少发生改变的，如果merge每个shard为一个segment，则该shard会使用很少的资源，查询也会快很多，我们可以采用optimize api处理

如果去optimize被标记为strong的index则会占用IO并且影响index操作，但是设置为medium则不用太担心这些问题。

以前的数据会有replicas，这样会比较浪费建议是先关闭replicas，然后optimize，最后restore replicas即可

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 }

没了replicas会增加丢失数据的风险，建议是先建立快照再操作。

closing old indices

老的index实在没有人会操作了那就可以选择关闭了，不建议你直接删除掉万一哪天你还会看呢，所以采用关闭就行了，别做事做绝了，no zuo no die

关闭之后还会存在cluster，但不会和未关闭的争抢资源

关闭前建议刷新一下，这样就可以保证在transaction log中没有遗留下transaction，空的transaction log会让重现打开更快。

POST /logs_2014-01-*/_flush 

POST /logs_2014-01-*/_close 

POST /logs_2014-01-*/_open