Sharding: Indexing

Indexing each database shard is basically similar to indexing a non-sharded database.
As each shard holds and manages a unique dataset, indexing is performed per-shard and indexes are stored only on the shard that created and uses them.

Map-Reduce Indexes on a Sharded Database

Map-reduce indexes on a sharded database are used to reduce data both over each shard during indexation, and on the orchestrator machine each time a query uses them.

1. Reduction by each shard during indexation
   Similarly to non-sharded databases, when shards index their data they reduce the results by map-reduce indexes.
2. Reduction by the orchestrator during queries
   When a query is executed over map-reduce indexes the orchestrator distributes the query to the shards, collects and combines the results, and then reduces them again.

Unsupported Indexing Features

Unsupported or yet-unimplemented indexing features include:

• Rolling index deployment
  Rolling index deployment is not supported in a Sharded Database.
• Loading documents from other shards
  Loading a document during indexing is possible only if the document resides on the shard.
  Consider the below index, for example, that attempts to load a document.
  If the requested document is stored on a different shard, the load operation will be ignored.
  

  Map = products => from product in products
                            select new Result
                            {
                                CategoryName = LoadDocument<Category>(product.Category).Name
                            };

  You can make sure that documents share a bucket, and can therefore locate and load each other, using the $ syntax.
  

• Map-Reduce Output Documents
  Using OutputReduceToCollection to output the results of a map-reduce index to a collection is not supported in a Sharded Database.
• Custom Sorters are not supported in a Sharded Database.