Реляционные и NoSql СУБД

если данные уже лежат в реляционной базе, значит они укладываются в реляционную модель

и зачем тогда?

В общем случае нет, не имеет никакого смысла.

Нет никакого смыла, юзал и то и другое, не вижу разницы. Разве что в каких-то крупных специфичных проектах…

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

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

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

Хотя в 99.9% случаев проще докинуть плашку оперативы и переделать кривые таблицы/индексы.

А если еще не лежат?

Тогда подумать, хочешь ли ты гонять курсоры руками или всё же писать запросы на sql это хорошая идея.

А если еще не лежат?

нет никакого «молоток лучше напильника»

сначала смотрим на задачу - потом подбираем инструмент

Если по каким-то причинам ты не можешь остаться в рамках однонодовой базы данных, то тебе приходится смотреть на распределенные системы. А оттуда на тебя смотрит cap-теорема. Дальше ты смотришь какие из буковок CAP для тебя важнее и выбираешь систему исходя из этого

MongoDB подходит для хранения всякого мусора в коллекциях. Там же можно хранить json-ины с любым набором полей, и только _id обязательно… Году в 2017 ее пиарили, хайпили, все на нее переезжали, а в итоге там «агрегации тормозят на коллекциях 10 миллионов записей» (не мои слова)

эээээ, может вопрос в разрезе того что сейчас уже в реляционные субд засунули все фичи из не реляционных, те же запросы к json.

Да то просто было продолжение всеобщей V8-мании, сначала выдрали браузерный js-движок и решили использовать его на сервере, а потом решили его как фронт для базы прикрутить… Сначала фронты начали писать бекенд, породив тонны быдлокода, потом принялись быдлобазы делать. Ну MongoDB и предполагает, что проект на Node.js будет с вероятностью 90%

менять имеющееся в NoSQL смысла не имеет.

стартовать существенно проще с Mongo или Couch. Пока данных относительно немного, что конкретно/часто запрашивается неясно, и модель данных не утрясётся.

А там либо старт принесёт прибыль на переезд, либо вы сэкономили время :-)

Монга же не свободная стала.

БД выбирают исходя из потребностей, а не «давайте сменим одно на другое и посмотрим». Если у тебя отсутствует понимание происходящего - лучше не лезь туда вообще.

Потребность попробовать что-то новое тоже потребность. :)

Как-то раз в IRC обсуждали эту тему, один чувак написал примерно следующее: у него в рабочем проекте в PostgreSQL была таблица под названием MongoDB с двумя полями: id (uuid) и data (jsonb).

Может быть, только если тебе совсем не нужны транзакции и джойны (декартово произведение). По крайней мере, в кассандре этого не было

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

Есть ещё 2 варианта - база по типу ключ-значение требующая максимальной производительности

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

Они в принципе для разного.

Более того, слушал несколько историй, как в больших проектах суют NoSQL-ную СУБД ПЕРЕД PostgreSQL для ускорения критических вещей, а потом информация всё равно в Postgre складывается. ЕМНИП, это чуть ли не про avito.ru было.

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

Есть же нормальные базы типа YDB где все это «натягиванием микро/макро сервисов и протоколом между» под капотом уже есть.