Какова реальная сфера применения MongoDb?

Question

[Макс]

Всем привет. Я немного отстал от "модных и молодежных" технологий и решил наверстать упущенное. Сейчас вот разбираюсь с MongoDb и пытаюсь понять для себя где я могу это применить.
В интернете приводятся в основном примеры с блогом. Но, если я правильно понял суть монги, то это вообще не ее ниша. Поскольку, по моему скромному мнению, блог должен писаться с использованием реляционной БД.
Ведь в блоге есть автор, у которого есть статьи, которые в свою очередь связаны с категориями, тегами и т.д. А еще у статей есть комментарии. Получается, что связей становится очень много.
Как правило при выводе статьи на странице мы указываем практически все ее связи (никнейм автора, теги, категории, комментарии с никнеймами авторов и т.д.).
Если хранить это в монге в отдельных коллекциях, и при каждом запросе все это собирать кучей запросов, то зачем вообще тогда использовать монгу с таким количеством реляций ведь для этих целей больше подойдет реляционная БД. Разве я не прав?

По скольку весь мой многолетний опыт связан именно с реляциями, мне достаточно трудно придумать реальную сферу применения монги. Единственное, что приходит на ум это:
1. Логирование действий пользователя на сайте (тут как правило всего одна реляция, к тому же мы всегда ищем по userId)
2. Микросервисы. Когда основное приложение генерирует какой-то набор данных, кладет его в монгу, а дальше микросервис их оттуда забирает и делает то, что нужно, например конвертирует файл с указанными настройками. Делал нечто подомное с использованием DynamoDb (по сути та же монга, только от амазона).
3. Так же, тут, на тостере встретил пример про мед. карты пациентов, когда в них записываются разного рода анализы и показания с различных аппаратов.

Вот и встает вопрос, где еще можно применить монгу? Меня не интересуют ответы в стиле "Там, где мало реляционных данных и документы не сильно связаны" и "Там, где у каждого документа может быть только 5-6 общих колонок, а остальные могут быть разными" или "Там, где нужна масштабируемость". Меня интересуют именно реальные и живые примеры, которые встречаются на практике.

Comments

[sim3x]

Лучше - нигде

[d'Ivan]

Стоит ещё отметить статью на Хабре: https://habr.com/ru/post/446180/

Answer 1

[lega]

Монга перекрывает 80-90% функционала sql-баз если рассмартивать средний проект, но дополнительно дает бо'льшую скорость работы, скорость и гибкость разработки, ну и масштабирование из коробки.
А от хейтеров вы осбо хорошего и не услышите ;-)

Ведь в блоге есть автор, у которого есть статьи, которые в свою очередь связаны с категориями, тегами и т.д. А еще у статей есть комментарии.

Категории, теги, да и сам автор может быть уже на клиенте, особенно если это веб-приложение, в этом случае реляции не обязательно подгружать, таким образом идет экономия поиска/чтения из базы и меньше трафика для передачи клиенту - т.е. выше производительность.
Так же автор может быть продублирован в документе (завсисит от задачи) и на крайний случай есть lookup и подобные способы.
Комментарии так же могут быть сохранены в самом документе, таким образом вы читаете из базы всего 1 документ, а не тысячу, что увеличивает скорость "на порядки".

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

Вообщем если нужна гибкость и скорость - то попробуйте монгу.

Comments

[sim3x]

Монга перекрывает 80-90% функционала sql-баз если рассмартивать средний проект

нет. Целосность не дает

дополнительно дает бо'льшую скорость работы, скорость и гибкость разработки, ну и масштабирование из коробки.

нет.
Скорость - постгрес быстрее монги на жсоне
Гибкость - посгтрес умеет работать с большим колличеством типов данных чем монга
Масштабирование из коробки миф у всех СУБД

Гибкость у noSQL сделана за счет переноса сложности разработки на плечи бекендера

[scorpioa]

sim3x, вы хоть какие-то ссылки на тесты дайте, только не с postgres сайтов :)
В 4й Mongodb есть транзакции.
Использую MongoDB: 4 shards с replica set + ElasticSearch. Перед использованием прошел бесплатные курсы от MongoDB University и провёл свой стресс тесты и был доволен.

[sim3x]

scorpioa, в

ы хоть какие-то ссылки на тесты дайте, только не с монго-сайтов :)

В 4й Mongodb есть транзакции.

значит там нет скорости

и был доволен.

яндекс и другие крупные компании - нет

[scorpioa]

sim3x, про яндекс , может все зависит от целей?
Опять же, пруф линки, т.к. балаболить каждый может ;)

[sim3x]

scorpioa, https://events.yandex.ru/lib/talks/2325/

[scorpioa]

sim3x, 2014 год выход лекции, Вы серьёзно )))) ?

[sim3x]

scorpioa,
Там в лекции были описаны проблемы - как они решены на момент 04.2019?

[lega]

sim3x, по лекции - автор сказал что их монга устраивает и он рекомендует её в 8 из 10 случаев, у них по сути проблема была только с шардингом (вполне вероятно что за 5 лет это уже исправлено).
Лекция очень старая - монга 2.х, сейчас монга значительно продвинулась, те же пункты как транзакции и глобальный лок - давно решены.
Итого 5 лет назад уже подходило для "8 из 10 случаев", а сейчас ещё лучше.

[ktulhu]

scorpioa, https://www.youtube.com/watch?v=SNzOZKvFZ68

[lega]

ktulhu, замечательный доклад,
вообщем чтобы постгрес "выиграл", в посгресе нужно выключить синхронизацию (т.е. значительно понизить надежность) и оперировать мелкими записями, т.к. после 2кб посгрес "складывается" и работает в разы медленее монги - это ответ почему хранение таблицами - устаревшый подход (не имеет отношение к sql/rdbms, чисто способ хранения). Ну и дополнительно замедлить монгу ключами w=1, j=1...

Надо будет перетестить, возможно в посгрес писали "в одну сессию"... (что дает ускорение в разы, но по сути используется только в тестах, а не в реальных приложениях).

И если взять например такой тест где 5% записей нужна синхронизация, а в 95% нет, то (судя по графикам) монга выдаст 50к, а посгрес 5к. Потому что посгрес не может менять режим на лету... а если ещё и тоаст учесть, то посгрес вообще будет в дауне - в 20-50 раз медленее могни.

Вообщем на средний проект и реальное использование - посгрес будет значительно медленее монги.

[lega]

ktulhu, так же в тесте монгу нагрузили всего на 70%, когда посгрес на все 100%, т.е. у монги был ещё не слабый запас, видимо иначе посгре бы не выиграл в этом тесте

[ktulhu]

lega, Рад, что вам понравилось, показывайте всем, какая Монга классная и быстрая и чем больше, тем лучше - мой бизнес в Северной Америке живет благодаря прогрессивным разработчикам, бросившим вызов истэблишменту и постоянно внедряющим все новые технологии. От всей души хочу поблагодарить вас за это - я обязан вам тем, что у меня на столе хлеб!

[spaceatmoon]

scorpioa,

MongoDB University

круто, прикольно когда компания заботиться о продвижении своего продукта.

Answer 2

[Max Abzalov]

Про пример с кучей запросов - lookup, много запросов делать не придется.
Из личного, на монге легко прототипировать, по ходу песни менять коллекции, связи и прочее.
В штатах часто делают сервисы про магазины и услуги, в монге есть специальные типы данных для хранения координат и поиску ближайшего, в радиусе и т.д.
Для блогов я бы взял лучше ES.
Из плюсов ещё можно отметить удобнейший драйвер из коробки на js, орм не нужна.
Логирование так же отлично подойдёт.
Ну и не забываем, что monga отлично масштабируется горизонтально, разные политики реплик позволяют весьма и весьма существенно увеличить предельную нагрузку малыми силами.

В свою очередь, хочу заметить, что с sql базами работал почти совсем мало, пробелов много, очень, но работать с ними проще, делать запросы на sql сильно легче, в монге той же можно заукуриться оптимизируя запросы.

Если идти дальше в NoSQL, есть разные подходы для реализации хранения данных, в монге это документ, в apache casandra - это ключ-значение, к примеру, у всего свои плюсы и минусы, писать их тут не буду, легко гуглится. Но и sql и nosql dbs выбирать нужно из соображений, что нужно бизнесу и очень часто в крупных проектах сейчас используются комбинации разных баз.

Comments

[Макс]

Но и sql и nosql dbs выбирать нужно из соображений, что нужно бизнесу и очень часто в крупных проектах сейчас используются комбинации разных баз.

В том то и дело, что в погоне за трендом некоторые разработчики забывают об этом. И лепят ее где надо и не надо. Поэтому и хочется определить для себя сферу ее применения.

[DestOny]

и sql и nosql dbs выбирать нужно из соображений, что нужно бизнесу

очень забавно. особенно было забавно, когда команда разработки одного гиганта как-то ни митинге предложила с постгреса на монгу перейти. Что смешного? А то, что 5 лет назад предыдущие разрабы мигрировали проект с монги на постгрес. И нет, их не уволили тогда из-за этого, просто в соседнюю команду перешли и они же это и упомянули на общем митинге.

Думается мне, что любой сервис можно как на монгу, так и на мускуль/постгру посадить. И там и там, при грамотном, использовании все будет быстро и качественно. Просто каждый двигает то, что ему нравится и что больше умеет.

В одной компании вообще видел редис в качестве основного хранилища, и все у них норм было.

Answer 3

[bro-dev]

Выбор бд зависит не от того что вы будете хранить, а от того какие запросы будут туда.

Answer 4

[grinat]

Она на рест ложиться хорошо, но главная фича это схема лесс и горизонтальное масштабирование из коробки. Там не нужны миграции, и можно как угодно изголятся с данными, вкупе с нетипизированным языком навроде js, это убойное сочетание, которое буквально за дни позволяет запустить полноценный прототип продукта. Nodejs+express+mongo это ядерная бомба, которыми стартап может взорвать рынок и легко пережить большую нагрузку в случае успеха. А в кровавом интерпрайзе я однажды абстракциями которые накидал за пару часов, с помощью тройки указанной выше, временно закрыл большую дырень в продукте(там по сути нужны были тупые crud'ы но для овердохриллион сущностей с кучей атрибутов), пока бакэнд не нагнал запоздание в сроках.

Comments

[Алексей]

Я бы сюда добавил еще, что с 4 версии Монго поддерживает ACID.
Потом монга поддерживает компрессию данных, чего не умеет из коробки перехваленый PostgreSQL

Answer 5

[Dimonchik]

гы-гы
вы сами ответили в п.2

сейчас же "эпоха биг-дата" - RDBMS хорошо безусловно, но - Вы alter table моментальный научились делать или как?
Монга преимущественно для складирования, да хоть бы и кеширования (хотя там варианты с аэроспайком на первых местах, но на любителя)
для транзакций, конечно, реляционные никто не отменял

Comments

[Макс]

Вы alter table моментальный научились делать или как?

Моментальный не научился. Но добавляться колонки с default null и последующим апдейтом порциями волне по силам. Неужто в big data боясь alter table стоит сразу делать выбор в сторону монги и ей подобных?

[xfg]

Макс, нет конечно. Для мелких сайтов РСУБД достаточно. Крупным нужно обрабатывать огромные массивы данных и здесь РСУБД становится уже не помощником, а проблемой. Данные необходимо шардить (делить) и оказывается невозможным использование джойнов и транзакций (между шардами) основных фишек реляционных баз данных и при этом еще необходимость писать и поддерживать свою систему шардинга на уровне приложения. Никаких плюсов от РСУБД не остается. Выбирают NoSQL, в частности mongo.

Про пинание трупов про которые тут пишут это не правда https://db-engines.com/en/ranking
В целом mongo это решение для любых современных веб-приложений, об этом было заявлено на официальном сайте. Поскольку она в духе интернета, который способен генерировать потенциально бесконечные объемы данных, а mongo соответственно их обрабатывать.

Answer 6

[funny_falcon]

Как минимум пара маркетплейсов использует mongodb.

Современная mongodb отличается надежной репликацией и фейловером, а также работающим шардингом. Когда база не влезает не то что на один сервер, а живет на сотне серверов (правда, с трехкратной репликацией), это начинает играть значение.

Какая еще распространенная опенсорс база из коробки, без сторонних костылей, позволяет такое развернуть?

Comments

[Алексей]

Cassandra