The scenario is
- having a cluster state of n alias, stored an master
- adding an alias to the master (what is time consuming here is the setup of alias filter query, this takes ~1 sec to validate and create the alias filter query, but it's not O(n))
- propagating the new cluster state of n+1 aliases to all nodes, and this is O(n) where n is the number of master eligible nodes
Step 3 runtime overweighs normally step 2. I'm assuming you add alias one-by-one, not all at once.
Propagating cluster state leads to a "dead time" of the whole cluster. It's a known challenge, not limited to index alias add operation. Lots of efforts went into cluster state management in ES 2.x compared to ES 1.x.
By observing this you have two options
-
add all aliases at once. With > 100k aliases, you create a large cluster state of several MBs. There are a plethora of problems with that, leading to question like "why are aliases stored in cluster state, why on a single master node first, why does it even propagate" and so on. This is a fundamental discussion, touching the ES design of single master node
-
reduce the number of nodes n that can carry cluster state (master eligible nodes)
But, in my opinion, since cluster state management has boundaries by design, you should reevaluate the massive amount of index aliases needed. There are several other options like
-
build a query proxy that receives the user ID and adds the user ID as a filter to each query
-
because index aliases are mostly addressed by REST API, instruct all REST clients how to filter for user ID by query for themselves
-
why using user IDs in that massive amount in only one single cluster etc.
The index alias feature is definitely not a feature where you can simply delegate a massive partitioning scheme like 100k user IDS of a giant index to ES while paying no price. Aliasing is not partitioning. It's adding the mechanics of the required query filter terms to the cluster state, and the cluster state must be moved throughout the whole cluster when it changes.
