我就像许多人正在考虑在Mongo中对我的收藏品进行分片的正确方法。主要问题是 - 自动分片是如何工作的？
官方文档说 - “MongoDB通过自动分片（分区）架构进行水平扩展”和“要对分区进行分区，我们指定了一个分片键模式。”注意“为集合选择正确的分片键很重要”:)。
http://www.mongodb.org/display/DOCS/Sharding+Introduction#ShardingIntroduction-ShardKeys
http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key
现在的问题是 - “这是正确的密钥”（按ObjectID分片）吗？
db.runCommand({ shardcollection : "test", key : { _id : 1 }})
Mongo内部发生了什么？在这种情况下，Mongo如何将数据拆分为块？假设我最初拥有10ml带有2个分片服务器的记录 - 当我想在集合达到20mln记录时再添加2个分片服务器时，Mongo方面会发生什么？我无法在Mongo相关来源的任何地方找到该级别的详细信息。
考虑到自生生_id的随机性及其结构，
... http://www.mongodb.org/display/DOCS/Object+IDs ...
我会通过最低有效字节（rtl顺序）进行分片，其中块被2-3个字节的值拆分 - 这将提供简单的方法来分片2 ^ N的分片服务器--2,4,8，..， 256个分片服务器，每个分片上具有或多或少的均匀负载，并且具有最少的所需配置。据我所知，Mongo仅通过明确定义的范围支持分片/分块，并且我的想法不起作用。是真的吗？
答案 0 :(得分：16)
使用默认对象id作为分片键通常不是一个好主意，因为它具有嵌入的时间戳并且在时间上单调增加。如果您进行大量更新，以便以均匀分布的方式触及旧文档和新文档，这可能会正常工作。但是，如果您的应用程序对插入很重要，那么这是非常坏的消息，因为大多数写入将转到单个分片。这是因为写入将转到拥有[nearCurrentTimestamp - ＆gt;的分片。无限大块。
每个mongos监视器将流量写入分片并使用非常简单的启发式方法来确定块是否变得太大并且需要拆分（阈值大小可通过chunkSize配置）。
当您向群集添加新分片时，平衡器（http://www.mongodb.org/display/DOCS/Sharding+Administration#ShardingAdministration-Balancing）将看到块不平衡，并将开始将块迁移到新分片。
Mongo支持基于范围的分片，但这并不意味着范围是固定的，因为分块可以分成更小的范围并随着时间的推移在群集中移动。
答案 1 :(得分：14)
2.4版本中令人兴奋的新功能是支持Hashed索引，可以用作分片键。那么你的主要问题的答案“用ObjectID进行分片，这是正确的方法吗？”现在可能是肯定的！
更多参考文献在官方文档中：
散列分片键
http://docs.mongodb.org/manual/core/sharded-cluster-internals/#hashed-shard-keys
哈希指数