【问题标题】:Mongo aggregation framework vs. javascript-like chaining: performanceMongodb 聚合框架与类 javascript 链接:性能
【发布时间】:2013-03-18 17:43:41
【问题描述】:

我读过聚合框架依赖于“管道”架构,即

db.myCollection.aggregate({
  $op1: { ... }
},{
  $op2: { ... }
})

另一方面,“传统”的 mongo 命令行查询语法也类似于管道:

db.myCollection.find({
  field: 'value'
}).filter({
  ...
}).forEach({
  ...
})
  1. 引擎盖下的实现有什么不同吗?
  2. “传统”语法也有点像管道 - 为什么存在替代语法?

【问题讨论】:

    标签: mongodb aggregation-framework


    【解决方案1】:

    引擎盖下的实现有什么不同吗?

    很多。例如,第一个在其 C++ 代码中作为聚合框架“在”MongoDB 中运行,而另一个在捆绑的 JS 控制台内的 V8/spidermonkey(取决于您的版本)环境中运行。

    很可能值得一提的是,您展示的后一种语法不是在“内部”MongoDB 中运行,而是在 JS 控制台中运行,该控制台具有通过 JS 驱动程序与 MongoDB 交互的能力。

    这适用于大多数数据库,例如 MySQL 控制台和许多其他数据库。它们只是捆绑的客户端程序。

    “传统”语法也有点像管道 - 为什么存在替代语法?

    因为控制台不是 MongoDB。

    【讨论】:

    • 请几个问题说清楚:(1)javascript接口是纯语法,(甚至共享管道感觉)与MongoDB内部实现无关。 (2) Aggregate 框架在 MongoDB 服务器端使用了特殊优化的管道实现。我对以上两个是正确的吗?如果是这样,为什么要重新引入不同的语法而不是将相同的旧语法绑定到更好的实现?
    • @BreakPhreak 关于要点和不同的语法,这是因为这需要从客户端调用,并且需要对代码进行评估,这是一种糟糕的实现方式,加上 SQL 类型像这样的结构允许使用 MR 不能使用的索引等。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-02-17
    • 2013-07-20
    • 2012-09-24
    • 1970-01-01
    相关资源
    最近更新 更多