OpenSearch에서 시간 기반 인덱스 사용의 장점

이 게시물은 OpenSearch Cluster에서 시간 기반 인덱스를 사용할 때의 몇 가지 장점을 나열합니다.

Increasing / Decreasing the number of shards becomes easy

Helps to plan cluster capacity and growth size

Easily determine optimum number of shards

Avoids having to reindex entire data

Efficient Deletion and application of ISM

Easy to include / exclude indices based on alias

Snapshot and Restore becomes a breeze with day-wise indices

Apply best_compression to day-wise indices

Force-merge past indices

1. day-wise 인덱스를 사용하는 샤드 수 증감 Say, an index template은 인덱스 설정에서 1 shard로 구성됩니다. 인덱싱 속도가 느리거나 샤드 크기가 너무 커지면(> 50GB) 인덱스 템플릿을 쉽게 수정하여 number_of_ shards를 3 또는 5로 늘릴 수 있습니다. 그리고 이것은 다음날부터 적용됩니다. 마찬가지로 일별 인덱스 패턴이 필요 이상의 샤드(oversharded)로 구성되어 있으면 줄이기가 쉬워진다.


2. 클러스터 용량 및 growth size

Let's say 100 events per second flow into an OpenSearch cluster and each event averages about 1 KB in size. Thus, per day, there would be:
86400 seconds * 100 events/second = 8,640,000 events.

Since each event averages about 1 KB, the total size of 8,640,000 events = 8,640,000 * 1 KB = 8,640,000 KB / (1024 * 1024) = ~8.24 GB .

Thus, with a day-wise index , we could see that the day-wise index size would be ~9 GB per day without any replicas. Considering 1 replica, the size per day would be ~18 GB and size for 30 days would be ~540 GB . This helps with capacity planning and estimating cluster growth rate.

계획을 돕습니다.
3. 최적의 샤드 수 With data set of about 9GB per day , for a day-wise index , we could start by setting "number_of_shards" : 1 in the index template를 쉽게 결정합니다. 각primary shard은 단일 샤드에 대해 상당히 합리적인 약 9GB이기 때문입니다. time-based 인덱스의 샤드는 40-50 GB 범위에 있을 수 있습니다.


4. 전체 데이터 reindex If the data influx increases, we could easily set "number_of_shards": 3 in the index template을 피해야 하며 이것은 tomorrow's 일별 인덱스에 적용됩니다. 데이터를 다시 인덱싱할 필요 없이 샤드 수를 쉽게 변경할 수 있습니다.


5. ISM Let's say we need to retain data upto 90 days. Thus, for a day-wise index which is older than 90 days , that entire index can be purged / deleted. This is far more efficient than purging records from indices.
Also, application of index state management 의 효율적인 삭제 및 적용이 시간 기반 인덱스로 단순화됩니다.


6. 새로 생성된 일별 인덱스에 매핑되는 인덱스 템플릿의 별칭 Let's assume the cluster needs to retain 90 days data but needs to search only on the last 60 days data. Alias to the rescue. In this case, define an alias 을 기반으로 인덱스를 쉽게 포함/제외합니다. 과거 인덱스가 60일이 지나면 해당 인덱스에서 별칭이 제거됩니다. 이렇게 하면 지정된 시점에서 별칭이 최대 60일 기준 인덱스를 가리킵니다.


7. 일별 인덱스를 사용하면 스냅샷 및 복원이 간편해집니다.

Say you have an index named my_index-2021.11.04 created on Nov 04, 2021. On Nov 05, 2021 at say 00:45 hours when data is no longer being written to the my_index-2021.11.04 , a snapshot, snap-my_index-2021.11.04 could be triggered for that index. This snapshot would contain just the my_index-2021.11.04 . In case the index is deleted and needs to be restored, it can be easily restored from the snapshot snap-my_index-2021.11.04 .

8. 일별 인덱스에 best_compression을 적용합니다.

    "settings": {
      "codec": "best_compression"
    }

사용 사례에 따라 "codec": "best_compression" 또는 그 이상에 도움이 될 수 있습니다. 마일리지가 달라집니다.

"codec": "best_compression"은 기존save disk space from 10% to 30% 인덱스에 동적으로 적용할 수 없습니다. 인덱스는 먼저 이어야 하고 설정은 동적으로 적용되어야 하고 인덱스는 The 이어야 합니다.

index template
9. open를 설정하여 과거 지수closedopened 를 강제 병합합니다. 이것은 검색 속도를 엄청나게 향상시킵니다.