MongoDB Documentation, Release 3.0.4 Pre-Split the Collection If the sharded collection is empty, then the collection has only one initial chunk , which resides on a single shard. MongoDB must then take time to receive data, create splits, and distribute the split chunks to the available shards. To avoid this performance cost, you can pre-split the collection, as described in Split Chunks in a Sharded Cluster (page 723). Insert to Multiple mongos To parallelize import processes, send bulk insert or insert operations to more than one mongos instance. For empty collections, first pre-split the collection as described in Split Chunks in a Sharded Cluster (page 723). Avoid Monotonic Throttling If your shard key increases monotonically during an insert, then all inserted data goes to the last chunk in the collection, which will always end up on a single shard. Therefore, the insert capacity of the cluster will never exceed the insert capacity of that single shard. If your insert volume is larger than what a single shard can process, and if you cannot avoid a monotonically increasing shard key, then consider the following modifications to your application: The following example, in C++, swaps the leading and trailing 16-bit word of BSON ObjectIds generated so they are no longer monotonically increasing. Example • Reverse the binary bits of the shard key. This preserves the information and avoids correlating insertion order with increasing sequence of values. • Swap the first and last 16-bit words to “shuffle” the inserts. See also: using namespace mongo; OID make_an_id() { OID x = OID::gen(); const unsigned char * p = x.getData(); swap( ( unsigned short &) p[0], ( unsigned short &) p[10] ); return x; } void foo() { // create an object BSONObj o = BSON( "_id" << make_an_id() << "x" << 3 << "name" << "jane" ); // now we may insert o into a sharded collection } Shard Keys (page 674) for information on choosing a sharded key. Also see Shard Key Internals (page 674) (in particular, Choosing a Shard Key (page 694)). New in version 3.0: MongoDB adds support for additional storage engines. MongoDB’s original storage engine, known as mmapv1 remains the default in 3.0, but the new wiredTiger engine is available and can offer additional flexibility and improved throughput for many workloads. Storage Data Model MongoDB stores data in the form of BSON documents, which are rich mappings of keys, or field names, to values. BSON supports a rich collection of types, and fields in BSON documents may hold arrays of values or embedded 89 3.2. MongoDB CRUD Concepts