MongoDB Documentation, Release 3.0.4 Cardinality Cardinality in the context of MongoDB, refers to the ability of the system to partition data into chunks . For example, consider a collection of data such as an “address book” that stores address records: The state key’s value holds the US state for a given address document. This field has a low cardinality as all documents that have the same value in the state field must reside on the same shard, even if a particular state’s chunk exceeds the maximum chunk size. Since there are a limited number of possible values for the state field, MongoDB may distribute data unevenly among a small number of fixed chunks. This may have a number of effects: • Consider the use of a state field as a shard key: – If MongoDB cannot split a chunk because all of its documents have the same shard key, migrations involv- ing these un-splittable chunks will take longer than other migrations, and it will be more difficult for your data to stay balanced. – If you have a fixed maximum number of chunks, you will never be able to use more than that number of shards for this collection. • Consider the use of a zipcode field as a shard key: • Consider the use of a phone-number field as a shard key: Shard a Collection Using a Hashed Shard Key Shard Key Selection Strategy For suggestions on choosing the right field as your hashed shard key, see Hashed Shard Keys (page 674). For limita- tions on hashed indexes, see Create a Hashed Index (page 521). Hashed shard keys (page 674) use a hashed index (page 521) of a field as the shard key to partition data across your sharded cluster. New in version 2.4. Therefore, the selection of a shard key is about balancing both your data and the performance characteristics caused by different possible data distributions and system workloads. Chapter 10. Sharding 696 When selecting a shard key, it is difficult to balance the qualities of an ideal shard key, which sometimes dictate opposing strategies. For instance, it’s difficult to produce a key that has both a high degree randomness for even data distribution and a shard key that allows your application to target specific shards. For some workloads, it’s more important to have an even data distribution, and for others targeted queries are essential. If you choose a shard key with low cardinality, some chunks may grow too large for MongoDB to migrate. See Jumbo Chunks (page 687) for more information. While “high cardinality,” is necessary for ensuring an even distribution of data, having a high cardinality does not guarantee sufficient query isolation (page 676) or appropriate write scaling (page 675). Phone number has a high cardinality, because users will generally have a unique value for this field, MongoDB will be able to split as many chunks as needed. In these cases, cardinality depends on the data. If your address book stores records for a geographically dis- tributed contact list (e.g. “Dry cleaning businesses in America,”) then a value like zipcode would be sufficient. However, if your address book is more geographically concentrated (e.g “ice cream stores in Boston Mas- sachusetts,”) then you may have a much lower cardinality. While this field has a large number of possible values, and thus has potentially higher cardinality, it’s possible that a large number of users could have the same value for the shard key, which would make this chunk of users un-splittable.