Mongodb Объясните для структуры агрегации

Ответ 1

Начиная с версии MongoDB 3.0, просто меняя порядок с

collection.aggregate(...).explain()

к

collection.explain().aggregate(...)

предоставит вам желаемые результаты (документация здесь).

Для более старых версий >= 2.6 вам нужно использовать параметр explain для операций конвейерной агрегирования

explain:true

db.collection.aggregate([
    { $project : { "Tags._id" : 1 }},
    { $unwind : "$Tags" },
    { $match: {$or: [{"Tags._id":"tag1"},{"Tags._id":"tag2"}]}},
    { $group: { 
        _id : "$_id",
        count: { $sum:1 } 
    }},
    {$sort: {"count":-1}}
  ],
  {
    explain:true
  }
)

Важное соображение в рамках структуры агрегирования заключается в том, что индекс может использоваться только для извлечения исходных данных для конвейера (например, использование $match, $sort, $geonear в начале конвейера) как последующие этапы $lookup и $graphLookup. После того, как данные были получены в конвейере агрегации для обработки (например, для прохождения через этапы, такие как $project, $unwind и $group), дальнейшая манипуляция будет выполняться в памяти (возможно, используя временные файлы, если установлена ​​опция allowDiskUse).

Оптимизация трубопроводов

В общем, вы можете оптимизировать конвейеры агрегации:

• Запуск конвейера с шагом $match для ограничения обработки соответствующих документов.
• Обеспечение начальных стадий $match/$sort поддерживается эффективным индексом.
• Фильтрация данных ранним использованием $match, $limit и $skip.
• Минимизация ненужных этапов и манипулирования документами (возможно, пересмотр вашей схемы, если требуется сложная гимнастика агрегации).
• Использование новых операторов агрегации, если вы обновили свой сервер MongoDB. Например, MongoDB 3.4 добавил много новых этапов и выражений агрегации, включая поддержку работы с массивами, строками и гранями.

Существует также ряд Оптимизация конвейерных агрегатов, которые автоматически происходят в зависимости от версии сервера MongoDB. Например, смежные этапы могут быть объединены и/или переупорядочены для улучшения выполнения, не влияя на результаты вывода.

Ограничения

Как и в MongoDB 3.4, опция "Агрегационная структура explain" предоставляет информацию о том, как обрабатывается конвейер, но не поддерживает тот же уровень детализации, что и режим executionStats для запроса find(). Если вы сосредоточены на оптимизации первоначального выполнения запроса, вам, скорее всего, будет полезно просмотреть эквивалентный запрос find().explain() с помощью executionStats или allPlansExecution verbosity.

Есть несколько релевантных запросов функций, чтобы наблюдать/повышать рейтинг в отслеживателе проблем MongoDB в отношении более подробной статистики исполнения, чтобы помочь оптимизировать/обобщать конвейеры агрегации:

• SERVER-19758: добавьте опции "executeStats" и "allPlansExecution" для объяснения агрегации
• SERVER-21784: отслеживать статистику исполнения для каждого этапа конвейера агрегации и раскрывать через объяснение
• SERVER-22622: улучшите поиск $look, чтобы указать план запроса в коллекции "from"

Ответ 2

Начиная с версии 2.6.x mongodb позволяет пользователям делать объяснение с помощью структуры агрегации.

Все, что вам нужно сделать, это добавить объяснение: true

db.records.aggregate(
  [ ...your pipeline...],
  { explain: true }
)

Благодаря Рафе, я знаю, что это можно было сделать даже в 2.4, но только через runCommand(). Но теперь вы можете также использовать агрегат.

Ответ 3

Структура агрегации представляет собой набор инструментов аналитики в MongoDB, который позволяет нам запускать различные типы отчетов или анализ документов в одной или нескольких коллекциях. На основе идеи трубопровода. Мы берем ввод из коллекции MongoDB и передаем документы из этой коллекции через один или несколько этапов, каждый из которых выполняет на нем разные операции. Каждый этап принимает входные данные независимо от того, на какой стадии он был создан в качестве выхода. Входы и выходы для всех этапов - это поток документов. Каждый этап имеет определенную работу, которую он выполняет. Он ожидает определенную форму документа и создает конкретный результат, который сам по себе является потоком документов. В конце конвейера мы получаем доступ к выходу.

Индивидуальный этап - это блок обработки данных. Каждый этап принимает входной поток документов по одному, обрабатывает каждый документ по одному и создает выходной поток документов. Опять же, по одному. На каждом этапе предусмотрен набор ручек или перегородок, которые мы можем контролировать для параметризации сцены для выполнения любой задачи, которую мы заинтересованы в этом. Таким образом, этап выполняет общую задачу - какую-то общую задачу и параметризует сцену для конкретного набора документов, с которыми мы работаем. И именно то, что нам хотелось бы, чтобы этот этап был связан с этими документами. Эти настройки обычно принимают форму операторов, которые мы можем предоставить, которые будут изменять поля, выполнять арифметические операции, изменять документы или выполнять какую-то задачу накопления, а также множество других вещей. Часто, это случай, когда мы хотим включить один и тот же тип сцены несколько раз в один конвейер.

например. Возможно, мы захотим выполнить начальный фильтр, чтобы нам не пришлось передавать всю коллекцию в наш конвейер. Но затем, после некоторой дополнительной обработки, хотите снова отфильтровать, используя другой набор критериев. Итак, чтобы понять, конвейер работает с коллекцией MongoDB. Они состоят из этапов, каждый из которых выполняет другую задачу обработки данных и вводит документы в качестве вывода, который должен быть передан на следующий этап. И, наконец, в конце конвейера получается выход, который мы можем сделать что-то в нашем приложении. Во многих случаях необходимо включать один и тот же тип сцены, несколько раз в рамках отдельного конвейера.