选择有利于读取性能的 MongoDB Shard Key答案

【问题标题】：Choosing a MongoDB Shard Key that benefits read performance选择有利于读取性能的 MongoDB Shard Key
【发布时间】：2013-09-01 07:41:53
【问题描述】：

我在很多地方都读到过，选择时间戳对于 Shard Key 来说是一个糟糕的选择，因为它会在插入时创建热点。如果我向 Shard Key 添加另一个或两个属性，它将创建更均匀的分布，但唯一可能有意义的其他属性不是用于查询的属性。这对于充分利用读取性能有多重要？

示例文档

{
  _id: <ObjectId>,
  user_id: <ObjectId>,
  _p:  <6-10 possible values>,
  ts:  <UNIX timestamp>,
  a:   'lorem ipsum',
  b:   <Array of ObjectId, can be null/empty>,
  ...,
  z:   'xyz'
}

此集合通常通过以下两种方式之一进行查询：

按 user_id（按时间戳排序）
由 b 和时间戳

如果我希望获得良好/更好的读取性能（写入增益对于我的用例而言是次要的），那么像以下之一的 Shard Key 是否是一个不错的选择：

{
  user_id:     1,
  timestamp:   1
}

或

{
  user_id:    1,
  _p:         1,
  timestamp:  1
}

或

{
  _p:         1,
  timestamp:  1
}

感谢您的帮助。

【问题讨论】：

标签： mongodb sharding

【解决方案1】：

如果您的数据中的时间戳很少更改，则分片键中的时间戳可能没问题。
你可以阅读the docs for shard key。好主意 - 用于“确保 MongoDB 能够在分片之间均匀分布数据”的分片键字段。然后在时间戳上创建索引。如果您的时间戳字段经常更改（插入具有新时间戳的数据），则将其用作分片键是个坏主意，因为 mongo 无法正常分发您的数据。

【讨论】：

时间戳本身（或任何单调递增的值，例如 ObjectID）是一个非常差的分片键选择。这将导致“热分片”性能问题，即所有数据在新数据到达时都被写入具有最高时间戳值的分片。 MongoDB 2.4+ 有一个hashed shard index，可用于均匀分布值，但代价是同时分布写入和读取。

【解决方案2】：

首先尝试仅按用户进行分片。如果这还不够，请添加 _p。当我们谈论分片时，试着想象一个有多个建筑物的图书馆。想想你怎么能把所有的书都放在所有的建筑物里。我认为时间戳不是这项工作的最佳解决方案。查找不可变数据（例如，在创建文档时设置一次）并按这些字段进行分片。

【讨论】：