We already have ~20 indexes.. as we grow more clients/customers can imagine hitting 100+ indexes. The response time currently seems to be fast (the "took" prop in the response shows ~50 ms).
But I am wondering what would happen when number of indexes increase? Would performance of this query fall? What is the time-complexity of this search? Or is there nothing to be concerned about?
The nature of this query requires to look for this data in every index, in every shard.
If you have a use-case like a timebased index, or another criteria to limit your searches, this might actually help to select the shards this query should be executed on.
oh. In every shard? that's a bit of a surprise, as I thought ES can efficiently route an id to a specific shard (I mean the way sharding itself works is based on id).
The idea was to find document with least meta info. It is need for fetching a document, whose id needs to be short enough to fit into a tiny url (like to be part of an sms or whatsapp message), that I decided to skip the index name from the tiny url. So.. I think I might have to refactor this to add the index name, and not do wildcard index search.
By default the document id is used for the routing as Christian (hey! ) mentioned.There are use-cases like the join field type where this needs to be set and you can configure the mapping to force the index operation to contain an explicit routing id - this is disabled by default though.
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.