如何选择合适的片键MongoDB的

我的文档结构是：如何选择合适的片键MongoDB的

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

uid是由关系数据库管理系统序列其他应用程序生成的用户ID。 yearmonth是我在应用中创建的人工领域，仅用于更好的分片键。

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

阅读模式：大多数查询都基于uid作为第一个查询参数。 {uid：“9999”，日期：{$ gt：....}，activityId：'login'}

我的初始分片键是{uid：1，date：1}。 - 如果任何一个uid文档太多，则提供良好的查询隔离并具有可拆分的块。现在，基于How to choose a shard key：卡片游戏文章和一些在这个论坛上的网络研讨会和评论，我认识到更好的密钥应该是 {粗糙的时间戳：1，搜索标准：1}。想法是要有更好的地方分片键来帮助写作表现。所以我创建yearmonth领域，考虑改变我的碎片键{yearmonth：1，UID：1}

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

来源

2012-12-11 eugened

我问过类似的问题：http://stackoverflow.com/questions/14798590/finding-a-good-index-and-shard-key-in-mongodb – stephanos

我只是坚持用uid，因为这是你要用来获取数据的关键。

碎片关键 - UID

特别是当它是一个随机UID基于事件的插入和读取，这将是非常优化，以保持uid的片键。

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

希望这会有所帮助。

来源

2012-12-20 18:57:12 muruga

如何选择合适的片键MongoDB的

回答

相关问题