anchor.diff:  * *TRAs*: Ways to automatically optimize (or reduce the resources of) older collections that aren't expected to receive more
     updates, and might have less search demand.
   
  -* *CRAs*: Intrinsic support for non-english text via base64 encoding
  -
  -* *CRAs*: Supply an initial list of values for cases where these are known before hand to reduce pauses during indexing
  -
  -* CloudSolrClient could route documents to the correct collection based on the route value instead always picking the
  +* *CRAs*: Intrinsic support for non-English text via Base64 encoding.
  +
  +* *CRAs*: Supply an initial list of values for cases where these are known before hand to reduce pauses during indexing.
  +
  +* `CloudSolrClient` could route documents to the correct collection based on the route value instead always picking the
     latest/first.
   
   * Presently only updates are routed and queries are distributed to all collections in the alias, but future
  
positive.code: // specific language governing permissions and limitations
  // under the License.
  
  == Standard Aliases
  
  Since version 6, SolrCloud has had the ability to query one or more collections via an alternative name. These
  alternative names for collections are known as aliases, and are useful when you want to:
  
  . Atomically switch to using a newly (re)indexed collection with zero down time (by re-defining the alias)
  . Insulate the client programming versus changes in collection names
  . Issue a single query against several collections with identical schemas
  
  It's also possible to send update commands to aliases, but only to those that either resolve to a single collection
  or those that define the routing between multiple collections (Routed Aliases). In other cases update commands are
  rejected with an error since there is no logic by which to distribute documents among the multiple collections.
  
  Standard aliases are created and updated using the <<collections-api.adoc#createalias,CREATEALIAS>> command.
  The current list of collections that are members of an alias can be verified via the
    <<collections-api.adoc#clusterstatus,CLUSTERSTATUS>> command.
  The full definition of all aliases including metadata about that alias (in the case of routed aliases, see below)
    can be verified via the <<collections-api.adoc#listaliases,LISTALIASES>> command.
  Alternatively this information is available by checking `/aliases.json` in zookeeper via a zookeeper
    client or in the <<cloud-screens.adoc#tree-view,tree page>> of the cloud menu in the admin UI.
  Aliases may be deleted via the <<collections-api.adoc#deletealias,DELETEALIAS>> command.
  The underlying collections are *unaffected* by this command.
  
  TIP: Any alias (standard or routed) that references multiple collections may complicate relevancy.
  By default, SolrCloud scores documents on a per shard basis.
  With multiple collections in an alias this is always a problem, so if you have a use case for which BM25 or
    TF/IDF relevancy is important you will want to turn on one of the
    <<distributed-requests.adoc#distributedidf,ExactStatsCache>> implementations.
  However, for analytical use cases where results are sorted on numeric, date or alphanumeric field values rather
    than relevancy calculations this is not a problem.
  
  == Collection admin commands and aliases
  Starting with version 8.1 SolrCloud supports using alias names in collection admin commands where normally a
  collection name is expected. This works only when the following criteria are satisfied:
  
  * an alias must not refer to more than one collection
  * an alias must not refer to a Routed Alias (see below)
  
  If all criteria are satisfied then the command will resolve alias names and operate on the collections the aliases
  refer to as if it was invoked with the collection names instead. Otherwise the command will not be executed and
  an exception will be thrown.
  
  == Routed Aliases
  
  To address the update limitations associated with standard aliases and provide additional useful features, the concept of
    RoutedAliases has been developed.
  There are presently two types of Routed Alias time routed and category routed. These are described in detail below,
    but share some common behavior.
  
  When processing an update for a routed alias, Solr initializes its
  
negative.code:   create more collections than expected during initial testing. Removing them after such events is overly tedious.
  
  As always, patches and pull requests are welcome!
  
  == Collection Commands and Aliases
  Starting with version 8.1 SolrCloud supports using alias names in collection commands where normally a
  collection name is expected. This works only when the following criteria are satisfied:
  
  * an alias must not refer to more than one collection
  * an alias must not refer to a <<Routed Aliases,Routed Alias>> (see below)
  
  If all criteria are satisfied then the command will resolve alias names and operate on the collections the aliases
  refer to as if it was invoked with the collection names instead. Otherwise the command will not be executed and
  an exception will be thrown.
  