Elasticsearch 6.0 ships with two great improvements to help minimize index storage size. The best part about the improvements is they will require no special configuration changes or re-architectures, and in most cases will only require a simple upgrade and a newly created index. To illustrate the improvements, we’ll use Metricbeat, a lightweight tool for ingesting metrics into Elasticsearch.
Elasticsearch 6.0 에는 index storage 크기를 최소화하기 위한 2가지 개선된 기능이 포함되어 있다. 개선 사항에 있어 가장 좋은 부분은 특별한 구성 변경이나 재구축이 필요하지 않으며, 대부분의 경우 간단한 upgrade와 새로 생성된 index만 필요하다. 개선 사항을 설명하기 위하여, Elasticsearch에 metics를 수집하는 경량 tool인 Metricbeat 를 사용할 것이다.
After running Metricbeat for several days on both Elasticsearch 5.6 and Elasticsearch 6.0 (6.0 beta2), index sizes were 41.5% smaller for the Metricbeat workload on Elasticsearch 6.0:
Elasticsearch 5.6 과 Elasticsearch 6.0 (6.0 beta2) 양쪽에 며칠 동안 Metricbeat를 실행한 후, index 크기는 Elasticsearch 6.0의 Metricbeat가 41.5% 더 작았다.
Elasticsearch 5.6
GET _cat/indices?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open metricbeat-2017.09.16 0b46voluSDmzfwCdYmYvZg 5 1 1694709 0 508.6mb 508.6mb yellow open metricbeat-2017.09.17 UKrTuwevS3urZkjeU8GFhg 5 1 1694385 0 500.7mb 500.7mb yellow open metricbeat-2017.09.18 dxFeMlabR_anYZ_C6BBq4A 5 1 1696223 0 512.7mb 512.7mb
Total storage size over 3 days: 1.522gb
3일에 걸친 전체 storage 크기는 1.522gb이다.
Elasticsearch 6.0
GET _cat/indices?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open metricbeat-2017.09.16 7IK6c1bfSQCaFAp1i3axUQ 5 1 1696571 0 299.1mb 299.1mb yellow open metricbeat-2017.09.17 CcBCgLdfRESXH0UaGV6YCA 5 1 1695385 0 295.4mb 295.4mb yellow open metricbeat-2017.09.18 sZfCXx8ZReGzLIsjSFO4hA 5 1 1697063 0 296.1mb 296.1mb
Total storage size over 3 days: 890.6mb (41.5% improvement in storage space from Elasticsearch 5.6)
3일에 걸친 전체 storage 크기는 890.6mb이다. (storage 크기는 Elasticsearch 5.6에 비해 41.5% 향상)
The test above used Metricbeat with the System module.
위의 test는 System module과 함께 Metricbeat를 사용했다.
Deprecated _all field
The “_all” field was deprecated in Elasticsearch 6.0, this is the first part in the explanation for the storage space savings we’re seeing. If you’re unfamiliar with the “_all” field, it’s a special field used to concatenate all values together, making it easy to search everything. The “_all” field made it easy to get started with Elasticsearch, however, the “_all” field uses a lot of additional storage space (especially as values are duplicated).
"_all" field는 Elasticsearch 6.0 에서 deprecate되었다. 이것이 storage 절약에 대한 설명의 첫번째 부분이다. "_all" field에 익숙하지 않겠지만, 이것은 모든 값을 쉽게 검색할 수 있도록 모든 값을 모두 연결하는데 사용되는 특별한 field이다. "_all" field를 사용하면 Elasticsearch를 쉽게 시작할 수 있지만, "_all" field는 많은 추가 storage 공간을 사용한다. (특히, 값이 중복되면)
PUT /user_profiles/profile/1 { "userid" : "john123", "first": "John", "middle": "James", "last": "Smith", "city": "Alamo", "state": "California" }
The “_all” field for the document above now contains the terms [ “john123”, “john”, “james”, “smith”, “alamo”, “california” ].
위의 document에 대한 "_all" field는 [ “john123”, “john”, “james”, “smith”, “alamo”, “california” ] 를 포함한다.
Using the “_all” field, it was easy to search across all fields, however, we’re now duplicating a lot of values, and using more storage space:
"_all" field를 사용하면, 모든 field를 쉽게 search할 수 있지만, 많은 값이 중복되고 더 많은 storage 크기를 사용한다.
GET /user_profiles/_search { "query": { "match": { "_all": "john123 john james smith alamo california" } } }
With the deprecation of the “_all” field in Elasticsearch 6.0, we save space on indexing duplicate data. And if “_all” field functionality is still needed, the copy_to parameter should still be used in the index mapping.
Elasticsearch 6.0 에서 "all" field가 deprecate되면서, 중복 data를 index하는 공간을 절약할 수 있다. 그리고, "all" field 기능이 여전히 필요하다면, copy_to 매개변수를 index mapping에 사용해야 한다.
We ran a follow-up test to look at the effects of disabling “_all” in relational to the storage improvements we saw. When isolated, the deprecation of “_all” accounted for almost 40% of our index saving improvements (the other 60% was due to the sparse field improvements we’ll visit next).
후속 test를 실행하여, storage 개선 사항과 관련하여, "all" 비활성화 효과를 살펴보자. "_all" 의 deprecate는 40%의 index 절약 효과가 나타났다. (다른 60%는 다음에 살펴볼 분포도가 낮은 field때문이다)
Sparse Field Improvements
Elasticsearch 6.0 includes Lucene 7.0, which has a major storage benefit in how sparsely populated fields are stored (LUCENE-7407). Metricbeat, used in our test above, happens to use a lot of sparsely populated fields.
Elasticsearch 6.0 에는 Lucene 7,0 이 포함되어 있는데, 여기에는 분포도가 낮은 field가 저장되는 방식(LUCENE-7407)에 큰 이점이 있다. 위의 test에 사용된 Metricbeat는 분포도가 낮은 field를 많이 사용한다.
If you recall, doc values (the columnar data store in Elasticsearch) have allowed us to escape the limitations of JVM heap size to support scalable analytics on larger amounts of data. Doc values are a very good fit for dense values, where every document has a value for every field. But they have been a poor fit for sparse values (many fields, with few documents having a value for each field), where the matrix structure ends up wasting a lot of space.
recall을 하면, doc values(Elasticsearch에서 column data 저장소)는 JVM heap의 크기 제한을 벗어나, 더 많은 양의 data에 대해 확장 가능한 분석을 지원할 수 있다. doc values는 모든 document가 모든 field에 대해 값을 가지는 분포도가 높은 값을 경우에 아주 적합하다. 그러나, matrix 구조가 많은 공간을 낭비하는 분포도가 낮은 값(많은 field가 있지만, 각 field에 대한 값을 가지는 document가 거의 없는)에는 적합하지 않다.
If you’re unsure of what a sparsely populate field is, it’s a field that contains a value for a small percentage of documents. For instance, if we go back to our user profile example, the “middle”, “city”, and “state” fields may only be present in a few of the documents:
분포도가 낮은 field가 무엇인지 확실하지 않다면, 그것은 적은 비율의 document에 대해 값을 포함하는 것이다. 예를 들어, 사용자 정보 예제를 보면, "middle", "city", "state" field는 일부 document에만 존제할 뿐이다.
Internally, Lucene 7.0 (which ships with Elasticsearch 6.0) retrieves data within doc values as an iterator, which allows for more efficient data storage behind the scenes (especially for sparsely populated values):
내부적으로, Lucene 7.0(Elasticsearch 6.0 이사용하는)은 doc values 내에서 iterator로 data를 가져오므로, 보다 효율적인 data 저장이 가능하다. (특히, 분포도가 낮은 값일 경우)
As you can see from the diagram above, with random access retrieval for doc values (present in Elasticsearch versions prior to 6.0), blank/empty values must be maintained (and extra storage space used). The iterator based approach does not need to store the empty/blank values, and the extra storage space used by the random access method can be reclaimed.
위 그림에서 볼 수 있듯이, doc values에 대란 random access를 사용(Elasticsearch 6.0 이전 version)하면, 빈 값을 유지해야 한다 (그리고, 추가 storage 공간을 사용해야 한다). iterator 기반의 방식늠 빈 값을 저장할 필요가 없고, random access 방식에서 사용되는 추가 storage 공간을 회수할 수 있다.
In addition to storage improvements, the iterator-based retrieval method for sparsely populated fields has a number of performance improvements, including indexing speed. Sparse fields should still be avoided when they can be, as dense fields are the most efficient. More details can be found in LUCENE-7253.
storage 개선외에도, 분포도가 낮은 field에 대한 iterator 기반의 방식은 index 속도를 포함한 많은 성능 개선이 있다. 분포도가 높은 field가 가장 효과적이므로, 분포도가 낮은 field는 가능한 한 피해야 한다. 더 자세한 사항은 LUCENE-7253 을 참고하자.
Both of these space saving improvements are present in Elasticsearch 6.0. We hope you’ll be happy with the new improvements, and look forward to hearing your feedback! If you want to try out Elasticsearch 6.0 for yourself, to determine any index storage size improvements, download 6.0.0-beta2 and become a pioneer!
이러한 공간 절약 개선은 모두 Elasticsearch 6.0 에 있다. 새로운 개선 사항으로 도움이 되길 바라며, feedback을 기대하겠다. index storage 크기 개선을 확인하기 위해, Elasticsearch 6.0을 직접 사용해 보고 싶다면, 6.0.0-beta2 을 다운로드해 보자.