6-4-09. Retiring Data

As time-based data ages, it becomes less relevant. It’s possible that we will want to see what happened last week, last month, or even last year, but for the most part, we’re interested in only the here and now.

시간 기반의 데이터는 오래 될수록, 관련성이 적어진다. 지난 주, 지난 달, 심지어 지난해에 무슨 일이 있었는지 알고 싶을 수도 있지만, 대부분의 경우, 지금, 여기에만 관심이 있다.

The nice thing about an index per time frame is that it enables us to easily delete old data: just delete the indices that are no longer relevant:

기간별 index의 좋은 점은 쉽게 오래된 데이터를 삭제하는 것이 가능하다는 것이다. 더 이상 관련 없는 index를 삭제하면 된다.

DELETE /logs_2013*

Deleting a whole index is much more efficient than deleting individual documents: Elasticsearch just removes whole directories.

전체 index를 삭제하는 것은, 개별 document를 삭제하는 것보다, 훨씬 더 효율적이다. Elasticsearch는 전체 디렉토리를 삭제한다.

But deleting an index is very final. There are a number of things we can do to help data age gracefully, before we decide to delete it completely.

하지만 index를 삭제하는 것은 최후 의 작업이다. 완전히 삭제하기로 결정하기 전에, 데이터를 위해 할 수 있는 몇 가지 일이 있다.

Migrate Old Indicesedit

With logging data, there is likely to be one hot index—the index for today. All new documents will be added to that index, and almost all queries will target that index. It should use your best hardware.

로깅 데이터에서, 오늘 생성된 index는, hot 한 index가 될 것이다. 모든 새로운 document가 해당 index에 추가될 것이고, 거의 모든 query가 해당 index를 대상으로 할 것이다. 그것은 최고의 H/W를 사용해야 한다.

How does Elasticsearch know which servers are your best servers? You tell it, by assigning arbitrary tags to each server. For instance, you could start a node as follows:

Elasticsearch는 어느 서버가 가장 좋은 서버인지 어떻게 알까? 각 서버에 임의의 tag를 할당해 주면 된다. 예를 들어, 아래와 같이, node를 시작할 수 있다.

./bin/elasticsearch --node.box_type strong

The box_type parameter is completely arbitrary—you could have named it whatever you like—but you can use these arbitrary values to tell Elasticsearch where to allocate an index.

box_type 매개변수는 완전히 임의적(원하는 대로 이름을 붙일 수 있다)이다. 그러나, index를 어디에 할당하려 하는지 Elasticsearch에게 알려 주기 위해, 이런 임의의 값을 사용할 수 있다.

We can ensure that today’s index is on our strongest boxes by creating it with the following settings:

다음과 같은 설정을 가지고, index를 생성하면, 오늘 생성된 index가 가장 좋은 박스에 있다는 것을 보장할 수 있다.

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

Yesterday’s index no longer needs to be on our strongest boxes, so we can move it to the nodes tagged as medium by updating its index settings:

어제 생성된 index는 더 이상 가장 좋은 박스에 있을 필요가 없다. 따라서, index 설정을 업데이트하여, medium 이라 tag된 node로 그것을 옮길 수 있다.

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

Optimize Indicesedit

Yesterday’s index is unlikely to change. Log events are static: what happened in the past stays in the past. If we merge each shard down to just a single segment, it’ll use fewer resources and will be quicker to query. We can do this with the optimize API.

어제 생성된 index는 거의 변경되지 않을 것이다. 로그 이벤트는 정적이다. 과거에 일어난 일은 과거에서 그대로 유지된다. 각각의 shard를 하나의 segment로 병합하면, 더 적은 자원을 사용할 것이고, query는 더 빨라질 것이다. optimize API로 이것을 할 수 있다.

It would be a bad idea to optimize the index while it was still allocated to the strong boxes, as the optimization process could swamp the I/O on those nodes and impact the indexing of today’s logs. But the medium boxes aren’t doing very much at all, so we are safe to optimize.

여전히 strong 박스에 할당되어 있는 동안에, index를 최적화하는 것은 좋은 생각이 아니다. 왜냐하면, 최적화 프로세스는 해당 node에 I/O를 계속할 것이고, 오늘의 로그를 색인 하는데 영향을 끼칠 수 있기 때문이다. 그러나, medium 박스는 전혀 그렇지 않다. 따라서 최적화에 안전하다.

Yesterday’s index may have replica shards. If we issue an optimize request, it will optimize the primary shard and the replica shards, which is a waste. Instead, we can remove the replicas temporarily, optimize, and then restore the replicas:

어제 생성된 index는 replica shard를 가지고 있을 수 있다. 최적화 request를 하면, primary shard와 replica shard를 최적화할 것이다. 그것은 낭비이다. 대신, replica를 임시로 제거하고, 최적화하고, 그 다음에 replica를 복구할 수 있다.

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 }

Of course, without replicas, we run the risk of losing data if a disk suffers catastrophic failure. You may want to back up the data first, with the snapshot-restore API.

물론, replica가 없으면, disk에 돌발적인 문제가 발생하는 경우, 데이터를 잃어버릴 위험이 있다. snapshot-restore API로, 먼저 데이터를 백업할 수 있다.

Closing Old Indicesedit

As indices get even older, they reach a point where they are almost never accessed. We could delete them at this stage, but perhaps you want to keep them around just in case somebody asks for them in six months.

index가 더 오래 되면, 거의 액세스되지 않는 순간에 도달한다. 이 순간에, index를 삭제할 수 있지만, 6개월쯤 후에 누군가가 그것을 요구하는 경우에 대비하여, 유지하려 할 수도 있다.

These indices can be closed. They will still exist in the cluster, but they won’t consume resources other than disk space. Reopening an index is much quicker than restoring it from backup.

이들 index는 닫을 수 있다. 여전히 cluster에 존재하지만, 디스크 공간 이외의 자원을 사용하지 않는다. index를 다시 여는 것이 백업에서 restore하는 것보다 훨씬 빠르다.

Before closing, it is worth flushing the index to make sure that there are no transactions left in the transaction log. An empty transaction log will make index recovery faster when it is reopened:

닫기 전에, 트랜잭션 로그에 남아 있는 트랜잭션이 없는지 확인하기 위해, flush를 해야 한다. 빈 트랜잭션 로그는 index를 다시 열 경우에, 더 빠르게 index를 복구한다.

POST /logs_2014-01-*/_flush 
POST /logs_2014-01-*/_close 
POST /logs_2014-01-*/_open 

	트랜잭션 로그를 비우기 위해, 1월의 모든 index를 flush한다.
	1월의 모든 index를 닫는다.
	다시 액세스해야 하는 경우에, open API로 다시 연다.

Archiving Old Indicesedit

Finally, very old indices can be archived off to some long-term storage like a shared disk or Amazon’s S3 using the snapshot-restore API, just in case you may need to access them in the future. Once a backup exists, the index can be deleted from the cluster.

마지막으로, 매우 오래된 index는 미래에 그들에 액세스할 필요가 있는 경우, snapshot-restore API를 사용하여, 공유 디스크나 Amazon의 S3같은 장기 보관 저장소에 보관할 수 있다. 백업이 존재하면, 해당 index는 cluster에서 삭제될 수 있다.