Упражнения с MongoDb

В этом видео, погоняем MongoDb вдоль и поперёк, чтобы проверить ее производительность при использовании разных типов запросов с агрегациями и без них.

Содержание

00:00 | Приветствие, заставка и планы на это видео
04:22 | Знакомство с проектом для тестирования
12:10 | Работа с MongoDb через DataGrip
21:10 | Подготовка скриптов для тестирования при помощи k6
22:12 | Запускаем тесты на производительность

Результаты тестирования

100 записей

 

1000 записей

 

100000 записей

 

7000000 записей

 

Видео

Продолжим упражнения

После выхода видео появились комментарии с вопросами разного содержания, например: "добавьте индекс на Summary" или "как же тогда решать проблемы производительности". Решения всегда зависят от... (depend on). Нет однозначного ответа или рецепта для решения подобной задачи. Множество факторов влияют на принцип и тип решения. Первый вариант, наверное? самый простой добавить Indexes (впрочем, как и в других базах данных). Но тут нужно понимать, что индексы тоже могут стать краеугольными камнем в производительности. Вы же знаете, что индексы ускоряют выборку на чтение, и существенно замедляют операции на вставку/изменение/удаление записей.

Я решил продолжить упражнения с MongoDb. В качестве простого эксперимента просто давить индекс на поле Summary, чтобы проверить на деле работу индексов.

Я выполнил команду:

// добавление индекса
db.WeatherForecasts.createIndex({ Summary: 1 });

в ответ на эту команду я получил ответ:

Что говорит, о том, что индекс успешно создан. Кстати, время потребовалось 22 секунды. Напоминаю, что в базе данных всё еще 13_000_000 записей.

Запустил заново тесты, которые показаны на видео, и получил следующие результаты для aggregate и one-by-onw:

 

На этот раз оба теста завершились без падений. И результат, надо сказать, немного удивил меня. Теперь выборка по одной категории с подсчетов (то есть фильтрация) работает быстрее чем агрегация.  Тогда я добавил еще 13_000_000 записей. И снова запустил тесты:

 

Тогда я добавил еще 24 000 000 записей, в общей сумме теперь 50 000 000 записей. Запустил тесты:

 

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

Больше записей добавлять не стал, а решил зайти с другой стороны. Решил посмотреть как можно оптимизировать Aggregation для MongoDb. И вы знаете, можно оптимизировать даже Aggregation на MongoDb. Оказалось, что в кривых руках и калькулятор зависает! Это я про свои руки, потому что к сожалению (или к счастью) очень мало "общался" с MongoDb. И поэтому просто не знаю некоторых нюансов.

Есть разные способы оптимизации. например, один из них, просто добавить Projection. В итоге Aggregation догнал по производительность фильтрацию с индексами.

Заключение

MongoDb - очень быстрая база данных. Надо просто понимать, как работают document-ориентированные базы, чтобы в полной мере использовать все их преимущества. На самом деле, такой подход работает относительно любой концепции. Можно и молотком шурупы закручивать, и отверткой гвозди забивать.

Единственный "минус" MongoDb, как и всех других document-ориентированных в том, что они не реляционные. А значит за согласованностью данных (consistancy) в этих базах придется следить очень пристально и почти в "ручном" режиме. Делайте выводы, господа.

Ссылки