MongoDB uses sharding to provide horizontal scaling. These clusters support deployments with large data sets and high-throughput operations. Sharding allows users to partition a collection within a database to distribute the collec- tion’s documents across a number of mongod instances or shards . To distribute data and application traffic in a sharded collection, MongoDB uses the shard key (page 674). Selecting the proper shard key (page 674) has significant implications for performance, and can enable or prevent query isolation and increased write capacity. It is important to consider carefully the field or fields to use as the shard key. See Sharding Introduction (page 661) and Shard Keys (page 674) for more information. Sharding Indexes MongoDB Documentation, Release 3.0.4 Use indexes to improve performance for common queries. Build indexes on fields that appear often in queries and for all operations that return sorted results. MongoDB automatically creates a unique index on the _id field. As you create indexes, consider the following behaviors of indexes: See Indexing Strategies (page 546) for more information on indexes as well as Analyze Query Performance (page 111). Additionally, the MongoDB database profiler (page 227) may help identify inefficient queries. In certain situations, you might choose to store related information in several collections rather than in a single collec- tion. Consider a sample collection logs that stores log documents for various environment and applications. The logs collection contains documents of the following form: { log: "dev", ts: ..., info: ... } { log: "debug", ts: ..., info: ...} If the total number of documents is low, you may group documents into collection by type. For logs, consider main- taining distinct log collections, such as logs_dev and logs_debug . The logs_dev collection would contain only the documents related to the dev environment. Generally, having a large number of collections has no significant performance penalty and results in very good performance. Distinct collections are very important for high-throughput batch processing. When using models that have a large number of collections, consider the following behaviors: 149 4.2. Data Modeling Concepts • Each collection has a certain minimum overhead of a few kilobytes. • Each index, including the index on _id , requires at least 8KB of data space. • For each database , a single namespace file (i.e. <database>.ns ) stores all meta-data for that database, and each index and collection has its own entry in the namespace file. MongoDB places limits on the size of namespace files . • When active, each index consumes disk space and memory. This usage can be significant and should be tracked for capacity planning, especially for concerns over working set size. • Collections with high read-to-write ratio often benefit from additional indexes. Indexes do not affect un-indexed read operations. • Adding an index has some negative performance impact for write operations. For collections with high write- to-read ratio, indexes are expensive since each insert must also update any indexes. • Each index requires at least 8KB of data space. Large Number of Collections