MongoDB分片密钥为（ObjectId、ObjectId、RandomKey）。不平衡集合

我正试图用大约600万份文档来分割一个集合。以下是有关分片集群的一些详细信息

Mongod版本2.6.7，两个碎片，40%写入，60%读取

我的数据库收集了大约600万个文档。正常文档如下所示：

{

}

每个部门有多个（1,2，…100）子部门，每个子部门有多个事件。有10000个此类部门、30000个分部门和600万个活动。这个数字一直在增长

正常的读取查询包括扇区id、子扇区id。每个写入操作包括扇区id、子扇区id、uid（随机生成的唯一键）和其余数据

我尝试/考虑了以下切分键，结果如下所述：

a_id:哈希-->将不提供查询隔离，原因：\未将id传递给读取查询

b。扇区id:1、子扇区id:1、uid:1-->奇怪的分布：具有旧ObjectId的扇区很少会进入碎片1，具有中年扇区id（ObjectId）的扇区很少会在两个碎片之间均衡分布。具有最新ObjectId的几个扇区保留在碎片0上

c。subsector_id:哈希-->结果与切分键b相同

d。子部门id:1，uid:1-->与b相同

e。子部门id:散列，uid:1-->无法创建此类索引

f。uid:1-->写入是分布式的，但没有查询隔离

这种分布不均的原因可能是什么？根据给定的数据，什么是正确的切分键

---

我将其视为一种预期行为Astro，SectorID和SubSectorID是ObjectId类型，它包含时间戳作为前4个字节，这在本质上是单调的，并且总是指向相同的块（因此也是相同的碎片），因为它无法提供随机性，这也是您在点（b）中指出的

选择切分密钥的最佳方法是具有业务意义的密钥（与某些ObjectId字段不同），并且应该与一些哈希作为后缀混合，以确保在该密钥上进行良好的随机混合，从而实现均匀分布。如果你有一个部门名称和子部门名称，那么请尝试一下，让我们知道，如果它的工作使用

你可以考虑这个链接来选择正确的碎片键。

---

-$

示例文档中已经显示了为切分键考虑的唯一字段。不幸的是，没有像sectorName和/或subsectorName这样的字段可以作为查询或shard keyhmmm的一部分……有时，倒过来的ObjectId字段会给它带来随机性，并避免我上面提到的问题。你为什么不试试呢。听起来不错，但这意味着我们必须在每次get调用中进行更改，以反向传递sectorid和subsectorid。

      _id         : ObjectId,
      sector_id   : ObjectId,
      subsector_id: ObjectId,
      .
      .
      .

      Many event specific fields go here
      .
      . 
      created_at: Date,
      updated_at: Date,
      uid       : 16DigitRandomKey