第五部分 架构篇 第二十章 MongoDB Sharding 架构（ 片键选择）

1、选择片键

选择一个好的片键非常关键，如果选择了一个糟糕的片键，它可以立马或者在访问量变大时毁了你的应用程序，也有可能潜伏着，等待着，没准什么时候突然毁了你的应用程序。

另外一方面，如果你选择了一个好片键，只要应用程序还在正常运行，而且只要发现访问量提高就赶紧添加服务器，MongoDB就会确保一直正确地运行下去。

正如在前面所学的，片键决定了数据在集群中的分布情况，因此你会希望存在这样一个片键，它既能把读写分散开来，又能把正在使用的数据保持在一起，这些看似互相矛盾的目标在现实中却往往是可以实现的。

我们先挑片键的几个反面例子找茬，然后再拿几个较好的例子来琢磨一番，MongoDB的wiki上也有一页与选择片键相关且很不错的内容，可以看看。

1.1、小基数片键

一些人并不真正理解或者信任MongoDB自动分配数据的方式，所以他们总是沿着这么个思路来向：我有4个分片，所以应该用一个由4个可能的字段来做片键，这是一个非常糟糕的想法，为什么呢？

假设我们有一个存储用户信息的应用程序，每个文档有一个continent字段代表用户所在地区，其字段值可以是"Africa"、"Antarctica"、"Asia"、"Australia"、"Europe"、"North Ameraica"或者"south America"，考虑到我们在每个大洲都有一个数据中心--或许不包括南极洲，并且想从人们所在当地的数据中心为其提供用户数据，我们决定按该字段进行分片。

集合