【问题标题】:Need help to select sharding key in MongoDB需要帮助在 MongoDB 中选择分片键
【发布时间】:2020-05-11 05:54:36
【问题描述】:

对于我的应用程序,我需要对一个相当大的集合进行分片,整个集合将包含 app. 5000 亿份文件。

我有两个可以用作 Sharding Key 的潜在字段:

对于插入,Sharding Key 将在整个集群中均匀分布文档,我使用哪个字段作为 Sharding Key 并不重要。

对于查询,它是不同的。

  • Field(1) 通常是查询过滤条件的一部分,因此查询通常只在单个分片上处理。

  • 字段 (2) 通常不是查询过滤条件的一部分,因此查询将在所有分片上进行处理,并且通常多个分片将有助于最终查询结果。

哪个字段更适合用作 Sharding Key?我在 MongoDB 文档中没有找到关于该主题的任何内容。

两个字段具有相同的范围和非常相似的基数,不会有任何区别。通常查询返回的文档数量非常少(通常少于 20-30 个文档)。

【问题讨论】:

    标签: mongodb bigdata sharding


    【解决方案1】:

    在分片集群中,mongos 路由器根据存储在配置服务器上的可用分片键元数据来确定读取或写入操作的目标分片。

    对于插入任何一个 Sharding Key 都会均匀分布文档 在整个集群中,我使用哪个字段并不重要 分片密钥。

    当您插入一个文档时,它会有一个分片键,并且该文档将存储在指定的分片上。

    Field(1) 通常是查询过滤条件的一部分,因此查询 通常只会在单个分片上处理。

    分片键的主要目的是 (a) 将数据均匀地分布在集群中的分片上,以及 (b) 能够以查询针对单个分片的方式查询数据。

    对于针对单个分片的查询,分片键必须是查询过滤条件的一部分。 mongos 路由器将使用分片键定位单个分片。

    如果分片键不是过滤条件的一部分,它将是一个分散-收集操作(一个长时间运行的查询)。使用分片集合的应用程序最重要的查询操作必须能够使用分片键,这一点很重要。

    Field(2) 通常不是查询过滤条件的一部分,因此 查询将在所有分片上处理,通常是几个分片 将有助于最终查询结果。

    当分片键不是查询过滤器的一部分时,该操作将跨越多个分片(分散-收集操作)并且运行速度会很慢。 mongos 路由器将无法确定哪些 shard 有目标数据,将查询集群中的所有 shard 以返回最终结果。

    哪个字段更适合用作 Sharding Key?

    可以得出结论,必须将Field(1)用作shard key。

    请参阅有关分片键的文档并选择分片键@MongoDB docs on Shard Keys

    【讨论】:

    • 谢谢,通过使用表达式“scatter gather”,我找到了相关文档Read Operations to Sharded Clusters分片集群上的读取操作在定向到特定分片时效率最高。对分片集合的查询应包括集合的分片键。
    猜你喜欢
    • 1970-01-01
    • 2016-02-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-12-01
    • 1970-01-01
    • 2013-03-27
    • 1970-01-01
    相关资源
    最近更新 更多