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

(Roopendra) #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.

(Yannick Welsch) #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.

(system) #3

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