Though a trivial easy task, am curious as to whether or not this has a positive performance benefit.
curl -XPUT 'localhost:9200/my_index/_settings' -d '
{
"index" : {
"blocks" {
"read_only" : "true"
} } }
'
ElasticSearch is built with an open-source Lucene for high performance. The open-source Apache Lucene is made with Java, ElasticSearch internally uses Apache Lucene for indexing and searching.
Elasticsearch is fast. Because Elasticsearch is built on top of Lucene, it excels at full-text search. Elasticsearch is also a near real-time search platform, meaning the latency from the time a document is indexed until it becomes searchable is very short — typically one second.
I assume you mean 'search performance' (search time) since you try to make your index read-only.
Without any changes to index (add/delete), the search performance (search time) should be the same whether it's set to read-only or not.
In both cases, a shard may be optimized to have only one segment. There is no overhead to maintain/search increasing number of segments inside a shard. Also, there is no need to merge segments and refresh/flush as well.
Please refer to ElasticSearch official document: Dynamically updatable indices to understand how an index update is done by ElasticSearch.
Also, according to this discussion in Github, Aaron Mildenstein mentioned:
It has no improvement on performance whatever.
Technically speaking, once an index has been optimized to 1 segment per shard, and had bloom filters disabled, there's not really anything else at the software level that will improve performance in any way.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With