如何为 MongoDB 选择正确的分片键答案

【问题标题】：How to choose right shard key for MongoDB如何为 MongoDB 选择正确的分片键
【发布时间】：2012-12-11 01:29:08
【问题描述】：

我的文档结构是：

"_id": ObjectId("50c41fae0e708237dc7a5187"),
"uid": "999",
"appname": "authentication",
"activityId": "login",
"activityName": "login",
"date": ISODate("2012-12-09T05: 20: 46.117Z"),
"yearmonth": "201212"

uid 是其他应用程序从 RDMS 序列生成的用户 ID。 yearmonth 是我在应用程序中创建的人工字段，仅用于更好的分片键。

书写模式：当用户登录或在站点上执行特定操作时，我将事件写入 mongoDB。这意味着 uid 是相对随机的，具有非常高的基数。对于同一个 uid，我可以编写数百个事件。

阅读模式：大多数查询都基于 uid 作为第一个查询参数。 {uid:"9999",date:{$gt: ....}, activityId:'login'}

我的初始分片键是 {uid:1, date:1}。 - 如果任何一个 uid 有太多文档，则提供良好的查询隔离并具有可拆分的块。现在，基于How to choose a shard key：这个论坛上的纸牌游戏文章和一些网络研讨会和cmets，我意识到更好的关键应该是 {粗时间戳：1，搜索条件：1}。想法是为分片键提供更好的局部性以帮助提高写入性能。所以我创建了 yearmonth 字段并考虑将我的分片键更改为 {yearmonth:1, uid:1}

问题是：我是否因为更改而松散了查询隔离和读取操作的性能？我的查询参数将不再匹配分片键的第一个元素。

【问题讨论】：

我问了一个类似的问题：stackoverflow.com/questions/14798590/…

标签： mongodb sharding

【解决方案1】：

我会坚持使用 uid，因为这是您将用来获取数据的密钥。

分片键 - uid

特别是当它是一个基于随机uid的事件插入和读取时，保持uid作为shard key是非常理想的。

当块变大时，MongoDB 中的平衡器 将自动平衡不同分片服务器之间的块。所以这里也涵盖了你（因为自动平衡会处理一些分片服务器变得太大）。

希望这会有所帮助。

【讨论】：