[mongodb翻译]分片的限制(sharding limit)

安全

2.0版本程序将会支持sharding状态下面的认证模式。

与没有分片配置的区别

• 2.0版本以前，分片必须运行在可信任的安全模式，没有明确的安全策略。
• 在当前版本中，shard key一旦选定后就不能再更改了。
• 所有的（不是操作多个）更新、更新插入和插入操作必须包含完整的shard key。这会对使用映射库有些影响，因为此时你无法控制更新操作。

$where

$where在sharding下面可以使用。但是不要在$where函数中引用数据库对象(db object)。

db.eval

db.eval()不能在分片的集合上面使用。当然，你可以在未分片的集合上面使用db.eval().在分片环境可以使用map/reduce.

getPrevError

getPrevError在分片的数据库上面是不支持的，而且在将来的发行版本可能也不支持。如果这会给你带来麻烦，请告诉我们。

Unique Indexes

对于一个分片的集合，你可以为shard key指定唯一的条件约束。你也可以拥有其他的唯一索引当且仅当shard key是他们的属性的前缀。换句话说，mongodb不保证在多shard环境下的唯一性。只要没有唯一性的限制，你可以创建其他的非唯一性的索引。

规模限制

目标是支持最多1000个shards。到目前为止的对集群测试限制在一定数目的shards（比如100）。如果以后遇到规模上的限制，更多的信息将来会更新到这里。

对集合的大小没有硬编码的限制，但是请记住前面章节的描述。你可以创建一个分片的集合，然后向里面添加数据，相应的数据会添加到相应数量的shard中。当然，只要你的查询可以很快的查询到。

查询速度

包含了shard key的查询可以很快返回，查询速度和以前在未分片的环境做查询相当。

没有包含shard key的查询使用了分散/收敛的方法，它会将查询发给所有的shards。当你有10个shard时性能表现还不错，但当你有1000个shards，性能可能会很差劲（如果查询很少的话，性能也会表现的不错）。

对一个已经存在的集合分片

你可以对一个已经存在的集合进行分片，但是这里有一些限制。换一种说法，如果你有一个单节点（或者单一复制组），你想把它升级到分片配置，这是可能的。

目前的限制有大小和时间。

1. 大小：在1.6版本我们设置原始集合最大大小固定在25GB（在1.8版本增大到256GB）。这个限制将来会增大也可能会取消。如果你的应用超过了这个限制，并且你也对集合做了分片，那么它可以工作。但是所有你的数据都会从一个数据块开始，导致初始的分发非常慢。在实际应用中，如果你的集合中包含了很多大的文档，这个限制可能会更大一些（由于统计分裂计算点的方法）。一个变通的方案，是可以在db.config.settings中增大默认数据块大小（比如512M或者1GB），这样就使能了初始的分裂和迁移。这样当数据插入时，大的数据块就自然的分裂了。
2. 时间：当对一个已经存在的集合做分片时，请知晓这个过程会花费一些时间。分片是在后台进行的，所以其他操作不会被明显的受到影响。无论如何，将一个大的集合中的数据进行迁移/平衡会占用很多时间。例如一个拥有10个shard的系统中，集合中90%的数据需要迁移到其他地方以达到平衡（提醒只对大的集合做数据均衡，如果集合比较小（比如少于400MB）我们建议就不要对它分片了）。