# Review request for "Elasticsearch Survival Guide for Developers" blog post

**URL:** <https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411>\
**Category:** Elasticsearch\
**Created:** [May 29, 2019, 7:27pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411 "2019-05-29T19:27:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![vyazici](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vyazici/32/39927_2.png) [@vyazici](https://discuss.elastic.co/u/vyazici)\
**Post date:** [May 29, 2019, 7:27pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411/1 "2019-05-29T19:27:45Z")

</div>

Hello,

I have been working on a blog post titled [Elasticsearch Survival Guide for Developers](https://vlkan.com/blog/post/2019/04/25/elasticsearch-survival-guide/) for some months and I have just published it. Before embarking for a PR in blogosphere, I would appreciate reviews of the beloved Elasticsearch community. Let me know if there are any inaccuracies or anything that bugs you.

Best.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [May 29, 2019, 7:52pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411/2 "2019-05-29T19:52:45Z")

</div>

A few comments from a quick scan:

There is, as far as I can see, no mention of oversharding, and this is pretty much the #1 problem we see with users. I think it's worth a mention and maybe a link to a blog post [like this one](https://www.elastic.co/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster).

> Start first by setting `index.translog.durability` to `async` .

**Please don't recommend this**. It will cause less experienced users to experience data loss. The default durability setting is much safer, and normally performs just fine on good hardware.

In fact I think that whole paragraph on translog tuning is a little misleading for a "survival guide". There are lots of other things I'd look at for performance gains before turning to these settings.

> Adapt `index.refresh_interval` to your needs.

It might be best to leave this setting unset too. In recent versions, if you're indexing but not searching then there will be no refreshes taking place. From [the docs](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html#dynamic-index-settings):

> If this setting is not explicitly set, shards that haven’t seen search traffic for at least `index.search.idle.after` seconds will not receive background refreshes until they receive a search request.

> Compare-and-swap over `_version` field is poor man’s transactions

The preferred CAS operation uses `_primary_term` and `_seq_no`, since `_version` [has known issues](https://github.com/elastic/elasticsearch/issues/19269).

---

<div class="post-metadata">

**Author:** ![vyazici](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vyazici/32/39927_2.png) [@vyazici](https://discuss.elastic.co/u/vyazici)\
**Post date:** [May 29, 2019, 8:24pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411/3 "2019-05-29T20:24:35Z")

</div>

Thanks so much for the prompt reply @DavidTurner! I have corrected the points you mentioned and given credits to you.

---

<div class="post-metadata">

**Author:** ![vyazici](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vyazici/32/39927_2.png) [@vyazici](https://discuss.elastic.co/u/vyazici)\
**Post date:** [May 29, 2019, 8:41pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411/4 "2019-05-29T20:41:18Z")

</div>

Added the following bullet for oversharding:

> One of the greatest strenghts of Elasticsearch is sharding, that is, splitting the data into multiple nodes to exploit parallellization. There are many myths surrounding this subject. Recall that sharding of an index cannot be changed once it is set. This makes oversharding a pretty common pitfall for newcomers. Make sure you have done your homework right (that is, RTFM, such as [this one](https://www.elastic.co/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster)) before taking any decisions.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [June 26, 2019, 8:41pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411/5 "2019-06-26T20:41:20Z")

</div>

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