Is there any drawback of using best_compression while indexing in Elasticsearch?

Elastic Stack Elasticsearch
1

I am performing some test on tuning disk space for Elasticsearch index. I found some good tips to compress the elasticseach index size. Especially, If your use case is only show dashboard in Kibana. During these indexes sizing analysis I observed best_compression gives me 21% gain in disk space.

So my question is here,

Is there any drawback of using best_compression in elasticsearch?

If not, then why Elasticsearch not enable best_compression as a default index.codec instead of LZ4 compression ?

I tried to find answer to these questions, but I couldn't succeed. Can you please help me to understand it better. Thanks.

2

This blog post explains it best:

So what’s the catch? The stored fields (value of the _source field) are what’s compressed, so there’s only a performance penalty due to decompression when the stored fields are returned in the query response. When the size=0 parameter is added to the request (as is recommended for pure aggregations queries and what Kibana does under the covers), there is no decompression penalty. There is a small performance penalty at index time; in many cases, people will gladly give up the extra CPU required for compression in exchange for disk space but you’ll have to consider this in the context of your requirements.

2 Likes
3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.