Mongo Map-Reduce 还是 Sharding？

Question

所以我问了这个问题：

使用集群设置 Mongo

但是直到我阅读了答案并进行了更多研究后，我才知道得足够多。对于同时询问大约 100 个查询的快节奏系统，使用 Map-reduce 或分片更好吗？分片将跨集群替换我的数据，看起来它本质上是做一个 map-reduce 或排序。如果我要对此类查询使用 map-reduce，是否也应该使用集群来执行此操作？如果是这样，从一个 Mongo 服务器开始，然后使用集群并将 map-reduce 任务分发到集群有多容易？或者我对我认为我需要完成的事情感到困惑？

Answer 1

目前还不清楚将 map-reduce 与分片进行比较是什么意思。但简短的回答是：分片。

一般来说，您设计出 map-reduce 查询，您不希望一次执行 100 次 map-reduce 查询 - 您只会重载 mongo，因为这基本上意味着 100 次完整集合扫描都在同一时间运行。

如果您有现有 map-reduce 查询之一的示例 - 请将其添加到您的问题中。

关于分片，这一切都取决于您用于分片键的内容。

例如，如果您根据用户名对用户集合进行分片，

db.users.find()

将导致 mongos 将查询发送到所有分片并将结果集合并在一起（智能地）。将分片键添加到查询中：

db.users.find().sort({username: 1}).limit(100);

将使 mongos 可以选择一次与较少的 mongod 交谈。

一个更好的例子，如果你查询：

db.users.find({username: /^bob/})

mongos 将查询发送到分片，其分片键表明它们可以包含答案，很可能只有一台服务器，从而导致快速查询并且 mongos 没有额外的负载。

也许上面的例子对你来说不是新闻。

您现在发送到 mongo 的查询与您用于发送到分片数据库的语法相同。您要做的唯一不同的是（以前）分析要分片的键，以便您可以在必要时修改查询以合并分片键，从而使 mongos 能够充当代理而不是聚合器。

一个糟糕的分片键，或者只是没有利用你正在生成的查询中的分片，将导致 mongos 需要查询所有 mongod 服务器以获取所有查询，从而导致高负载和低性能。