Sharding Limits

Sharding Alpha 2 (MongoDB v1.1)

Work is still underway on replication/failover. For Alpha 2, please use a single mongod master per shard (and manual slaves if desired). Replica sets, which are intended for use with sharding, are coming: SERVER-557 .
group() is not supported in alpha 2. In generally, we recommend using the map/reduce facility in sharded environments.
Sharding must be ran in trusted security mode, without explicit security.

Shard Keys

Shard keys are immutable in the current version.
Compound shard keys are not yet supported, but will be in the future.

Differences from Unsharded Configurations

Sharded databases behave differently in certain circumstances from a standalone, single-server mongod instance.

$where

$where works with sharding. However do not reference the db object from the $where function (one normally does not do this anyway).

db.eval() may not be used with sharded collections. However, you may use db.eval() if the evaluation function accesses unsharded collections within your database. Use map/reduce in sharded environments.

getPrevError

getPrevError is unsupported for sharded databases, and may remain so in future releases (TBD).

Unique Indexes

For a sharded collection, you may only (optionally) specify a unique constraint on the shard key. Other secondary indexes work (via a global operation) as long as no unique constraint is specified.

Counts

Count is supported with sharding; however, a "count all in collection" will not be instantaneous for a sharded collection as it is for an unsharded collection.

Scale Limits

Goal is support of systems of up to 1,000 shards. Testing for Alpha 2 will be limited to clusters with a modest number of shards (e.g., 20). More information will be reported here later on any scaling limitations which are encountered.

MongoDB sharding supports two styles of operations -- targeted and global. On giant systems, global operations will be of less applicability.