<p dir="auto">Setting both options <code class="notranslate">"index.auto_expand_replicas":"0-all"</code> and <code class="notranslate">"cluster.routing.allocation.same_shard.host": true</code> causes unallocated shards in a cluster.</p>
<p dir="auto">E.g. in a cluster with 5 physical hosts and 10 Elasticsearch instances (2 instances/host) the settings cause 5 unallocated shards per an index.</p>
<p dir="auto">Is this the correct behavior?<br>
Thanks!</p>
<p dir="auto">P.S. Tested on Elasticsearch-1.4.4</p>
<p dir="auto">We already use fielddata on the <code class="notranslate">_uid</code> field today in order to implement random sorting. However, given that doc values are disabled on <code class="notranslate">_uid</code>, this will use an insane amount of memory in order to load information in memory given that this field only has unique values.</p>
<p dir="auto">Having better fielddata for <code class="notranslate">_uid</code> would also be useful in order to have more consistent sort order when paginating or hitting different replicas: we could always add a tie-break on the value of the <code class="notranslate">_uid</code> field.</p>
<p dir="auto">I think we have several options:</p>
<ul dir="auto">
<li>Option 1: Add SORTED doc values to <code class="notranslate">_uid</code></li>
<li>Option 2: Add BINARY doc values to <code class="notranslate">_uid</code></li>
<li>Option 3: Add SORTED doc values to <code class="notranslate">_type</code> and <code class="notranslate">_id</code></li>
<li>Option 4: Add SORTED doc values to <code class="notranslate">_type</code> and BINARY to <code class="notranslate">_id</code></li>
</ul>
<p dir="auto">Option 2 would probably be wasteful in terms of disk space given that we don't have good compression available for binary doc values (and it's hard to implement given that the values can store pretty much anything).</p>
<p dir="auto">Options 3 and 4 have the benefit of not having to duplicate information if we also want to have doc values on <code class="notranslate">_type</code> and <code class="notranslate">_id</code>: we could even build a BINARY fielddata view for <code class="notranslate">_uid</code>.</p>
<p dir="auto">Then the other question is whether we should rather use sorted or binary doc values, the former being better for sorting (useful for the consistent sorting use-case) and the latter being better for value lookups (useful for random sorting).</p>