MongoDB Documentation, Release 3.0.4 Query Isolation Generally, the fastest queries in a sharded environment are those that mongos will route to a single shard, using the shard key and the cluster meta data from the config server (page 670). For queries that don’t include the shard key, mongos must query all shards, wait for their responses and then return the result to the application. These “scatter/gather” queries can be long running operations. If your query includes the first component of a compound shard key $^{10}$, the mongos can route the query directly to a single shard, or a small number of shards, which provides better performance. Even if you query values of the shard key that reside in different chunks, the mongos will route queries directly to specific shards. To select a shard key for a collection: If this field has low cardinality (i.e not sufficiently selective) you should add a second field to the shard key making a compound shard key. The data may become more splittable with a compound shard key. Sharded Cluster Query Routing (page 678) for more information on query operations in the context of sharded clusters. Sorting In sharded systems, the mongos performs a merge-sort of all sorted query results from the shards. See Sharded Cluster Query Routing (page 678) and Use Indexes to Sort Query Results (page 548) for more information. Indivisible Chunks An insufficiently granular shard key can result in chunks that are “unsplittable”. See Create a Shard Key that is Easily Divisible (page 695) for more information. • determine the most commonly included fields in queries for a given application • find which of these operations are most performance dependent. • Considerations for Selecting Shard Keys (page 694) • Shard a Collection Using a Hashed Shard Key (page 696). 10 In many ways, you can think of the shard key a cluster-wide index. However, be aware that sharded systems cannot enforce cluster-wide unique indexes unless the unique field is in the shard key. Consider the Index Concepts (page 486) page for more information on indexes and compound indexes. Chapter 10. Sharding 676 A production (page 672) cluster has no single point of failure. This section introduces the availability concerns for MongoDB deployments in general and highlights potential failure scenarios and available resolutions. If each application server has its own mongos instance, other application servers can continue access the database. Furthermore, mongos instances do not maintain persistent state, and they can restart and become unavailable without losing any state or data. When a mongos instance starts, it retrieves a copy of the config database and can begin routing queries. Sharded Cluster High Availability Application Servers or mongos Instances Become Unavailable Additional Information See