Apache Solr Reference Guide Covering Apache Solr 6.0

Then at query time, you include the prefix(es) into your query with the _route_ parameter (i.e., q=solr&_rout
e_=IBM!) to direct queries to specific shards. In some situations, this may improve query performance because
it overcomes network latency when querying all the shards.
The _route_ parameter replaces shard.keys, which has been deprecated and will be removed in a
future Solr release.
The compositeId router supports prefixes containing up to 2 levels of routing. For example: a prefix routing
first by region, then by customer: "USA!IBM!12345"
Another use case could be if the customer "IBM" has a lot of documents and you want to spread it across
multiple shards. The syntax for such a use case would be : "shard_key/num!document_id" where the /num is the
number of bits from the shard key to use in the composite hash.
So "IBM/3!12345" will take 3 bits from the shard key and 29 bits from the unique doc id, spreading the tenant
over 1/8th of the shards in the collection. Likewise if the num value was 2 it would spread the documents across
1/4th the number of shards. At query time, you include the prefix(es) along with the number of bits into your
query with the _route_ parameter (i.e., q=solr&_route_=IBM/3! ) to direct queries to specific shards.
If you do not want to influence how documents are stored, you don't need to specify a prefix in your document ID.
If you created the collection and defined the "implicit" router at the time of creation, you can additionally define a
router.field parameter to use a field from each document to identify a shard where the document belongs. If
the field specified is missing in the document, however, the document will be rejected. You could also use the _r
oute_ parameter to name a specific shard.
Shard Splitting
When you create a collection in SolrCloud, you decide on the initial number shards to be used. But it can be
difficult to know in advance the number of shards that you need, particularly when organizational requirements
can change at a moment's notice, and the cost of finding out later that you chose wrong can be high, involving
creating new cores and re-indexing all of your data.
The ability to split shards is in the Collections API. It currently allows splitting a shard into two pieces. The
existing shard is left as-is, so the split action effectively makes two copies of the data as new shards. You can
delete the old shard at a later time when you're ready.
More details on how to use shard splitting is in the section on the Collections API.
Ignoring Commits from Client Applications in SolrCloud
In most cases, when running in SolrCloud mode, indexing client applications should not send explicit commit
requests. Rather, you should configure auto commits with openSearcher=false and auto soft-commits to
make recent updates visible in search requests. This ensures that auto commits occur on a regular schedule in
the cluster. To enforce a policy where client applications should not send explicit commits, you should update all
client applications that index data into SolrCloud. However, that is not always feasible, so Solr provides
the IgnoreCommitOptimizeUpdateProcessorFactory, which allows you to ignore explicit commits and/or optimize
requests from client applications without having refactor your client application code. To activate this request
processor you'll need to add the following to your solrconfig.xml:
Apache Solr Reference Guide 6.0
549