It looks like each route key is mapped to a single shard. If I have very
course route keys - say each one accounts for one tenth of my documents,
would it be best for me to create some kind of surrogate route key so that
my documents don't get assigned to just ten shards?
I'm pretty sure I could build the key in such a way so I'd know exactly
what it is on update but on search I'd need to list a bunch of them. Would
that be really inefficient on search?
Or is this a horrible idea and I'd be better of creating an index per route
key?
My guess is it's not a horrible idea and your searches shouldn't be slow if
you specify a bunch of routing keys. But I guess it's safer to test before
proceeding
If you have a small amount of "natural" routing keys, like 10, I think it's
easier to just make 10 indices and use
aliaseshttp://www.elasticsearch.org/guide/reference/api/admin-indices-aliases/when
you want to search through multiple routing keys. It just seems easier
for me, and as long as you don't have too many indices (eg: 200) in too
little nodes (eg: 2 small ones)
Best regards,
Radu
On Tue, Jul 23, 2013 at 6:03 PM, Nikolas Everett nik9000@gmail.com wrote:
It looks like each route key is mapped to a single shard. If I have very
course route keys - say each one accounts for one tenth of my documents,
would it be best for me to create some kind of surrogate route key so that
my documents don't get assigned to just ten shards?
I'm pretty sure I could build the key in such a way so I'd know exactly
what it is on update but on search I'd need to list a bunch of them. Would
that be really inefficient on search?
Or is this a horrible idea and I'd be better of creating an index per
route key?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
