Зачем используется две бд PostgresSQL и MongoDB/Redis?

Question

[Дмитрий Ларин]

Расскажите пожалуйста человеку, который до этого работал со стеком LAMP и не парился. Зачем две бд? Одна для больших данных, другая для "быстрых"?

Comments

[Andrey Tsvetkov]

Редис может быть использован в качестве кеширующей прослойки для запросов в медленный Постгре

Answer 1

[Максим Федоров]

Реляционная БД хорошо себя показывает для целостности данных, хорошая и крепкая структура... но есть минус — когда много связей и таблицы глубокие, то приходится делать очень большые и сложны запросы, некоторые могут выполняться долго...

Тогда делают денормализацию данных — объединяют несколько таблиц в один документ, например в документе с товаром будут сразу и варианты с ценами, и изображения и категория и комментарии, тогда при запросе этого документа по id идет 1 запрос и данные быстро отдаются.

Например если есть расписания для занятий, которые генерируется большими выборками, но при этом весь день акутальные, то можно на день закеширвоать результат и отдавать их по 1 запросу...

Также Редис используют для хранения в нем сессий https://habrahabr.ru/post/318836/

Comments

[Дмитрий Ларин]

Спасибо за развернутый ответ.

[InoMono]

Много связей - все плохо с РСУБД?

В Монге свои проблемы. Там много связей - она вообще стоит колом. Приходится денормализовывать. А это проблемы с консистентностью перекладывает на приложение.

Монга хорошо по кластеру размазывается. Это большой плюс. Но опять же проблемы при этом с консистентностью жуткие

[Дмитрий Ларин]

InoMono, задумался. Есть проект(пока только на бумаге) где много связанных данных. И в требованиях MongoDB/Redis. Без РСУБД. Думаю как это делать...

[Максим Федоров]

InoMono, нет, ничего не утверждал плохого

[InoMono]

Максим Федоров, денормализацию можно и в РСУБД делать. Ровно также как и в Монге.
А вот наоборот нельзя - Монга с хорошо нормализованным не живет под нагрузкой

Нашел доклады с конференции Хайлоад, где хорошо разъяснена разница. Привел их в своем ответе

[InoMono]

Дмитрий Ларин, зачем у вас в проекте такое требование?

Или это мода/хайп и заказчик повелся

Или он планирует это загнать в кластер так как будет взрывной рост

Или ему не нужна производительность. Может у него нагрузка то 2 запроса в час

Или у него уже есть Монга и он не хочет админить еще одну базу

[Максим Федоров]

InoMono, да, мои доводы касались Редиса в основном...

[InoMono]

Максим Федоров, ну да, Редис или нечто подобное (Tarantool, Aerospike) все равно как правило надо.
Не зависимо от того что есть Монго или MySQL

Answer 2

[InoMono]

Для разных целей - свои плюсы минусы. Если для ваших нагрузок хорош MySQL - то и не забивайте себе голову.

С Монгой или Постгресом сайт ваш не станет сам себя создавать все равно. А вот лишнего гемору много.

Ситуации когда этот лишний гемор того стоит - в этих двух видео прекрасно на свои места расставляется.

https://junior.highload.ru/2016/abstracts/2075.html

https://youtu.be/SNzOZKvFZ68

Если у вас не ХайЛоад с распределением базы на десятки и больше серверов кластера - вам вполне достаточно РСУБД (MySQL, Postgres). И никаких проблем с консистентностью.
Если хочется schemaless решение чтобы с миграциями не париться - то обратите внимание на JSONB в Postgres. Автор доклада на Хайлоад про это все тот же О.Бартунов.
Вполне может что вам понадобится БД работающая с БД в памяти - Redis, Tarantool, Aerospike.
Но Монго - это хорошо для кластеров.

Comments

[Дмитрий Ларин]

Есть такая штука в ТЗ - технические требования. Написано mongo значит mongo... Я бы и рад дальше пилить на мускуле, так ведь "фуфуфу", "старье"...ну и т.д.

[InoMono]

Дмитрий Ларин, ничуть он не старье. Свежие версии гляньте. Альтернативные реализации MySQL гляньте

[Максим Федоров]

InoMono, я вас понимаю,
но к сожалению не все инженеры в силах влиять на решения заказчиков, и это нормально... тем более не у всех есть степени свободы для проявления характера, когда могут быть факторы, заставляющие быстро работать не взирая на даже среднесрочную перспективу (апример есть заказ и есть нужда — дети, долги и прочее)

[InoMono]

Дмитрий Ларин, ТЗ - такая вещь

Не всегда нужно его принимать без обсуждения

Когда я ТЗ критикую и предлагаю свои варианты - мне больше платят

Потому как в первом случае я получаюсь просто программист. А во втором архитектор системы.

[Дмитрий Ларин]

InoMono, заказчики позиционируют себя как суперсовременных. фронт на реакте, бек на симфони, все в виде микросервисов...

[InoMono]

Дмитрий Ларин, я бы попытался продавить если не MySQL то Postgres.

Ну или выяснил бы их доводы за MongoDB.

Может они действительно хотят масштабироваться до мировых масштабов. Микросервисы на это намекают. А может им кто в уши надул.

В случае аналогичных "модных" заказчиков вполне удалось пролоббировать выбор СУБД под конкретный микросервис на основании личного выбора разработчика, ведущего этот микросервис.

Не любой прям на выбор. Но возможность выбора именно MongoDB и/или Postgres сделали для разработчиков. И автоматизировали возможность подключать ту или иную всего лишь строчкой кода в конфигурационном файле микросервиса.

Впрочем, возможно, что под вашу задачу и Монга подходит.

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

Собственно этот минус Монги является неотъемлимым следствием плюсов.