MongoDB vs SQL

1. 70% web-developer'ов про транзации слышали только в спорах

2. Раз не нужны - значит не нужны вообще. И почему они понадобятся, если раньше небыли нужны?

3. Потомоу что енет джойнов. Скейлинг нужен тем - кто проседает по IO в rdbms. Кому всё надо - берут оракл с партиционированием и мегасервер за тонны денег.

4. Можно, только нужны ли в JS сложные транзакции? А как жить с асинхронщиной, когда она полочит пол-БД ради того самого ACID-a.

Как жить без джоинов? Или они вообще не так уж нужны? Когда они нужны, а когда нет?

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

А если вдруг на готовом сайте, использующем MongoDB понадобятся, то что делать?

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

Можно ли в стеке MEAN MongoDB заменить на какую-нибудь реляционную базу данных (в идеале на PostgresQL - он вроде самый годный)?

А почему нет?

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ — прочитай это, неплохой репорт о подводных камнях. Заодно узнаешь о 1 и 2.

3 — спорно и зависит от ситуации.

http://video.fosdem.org/2015/devroom-mysql_and_friends/ua2114_baudoux_mysql_n...

Можно ли в стеке MEAN MongoDB заменить на какую-нибудь реляционную базу данных (в идеале на PostgresQL - он вроде самый годный)?

В постгрес 9.4 добавили тип данных JSONB - та же монга, только с ACID, улучшенной производительностью и более компактным хранением данных на диске.

Чувак, можно делать всё что хочешь. Выкинуть монгу - не проблема. На самом деле писать код с монгой, кoучдатaбейсом, арангодатабейсом - гораздо быстрее с нуля, те, кто используют обычные субд навроде mysql для ускорения написания кода тоже юзают аналог монго-подхода: orm. Там данными управляешь не как записями в таблице, а как объектами языка, через точку модифицируя их методами. Скейлятся обычные и документоориентированные субд примерно одинаково легко. Т.ч. никакой охеренной панацеи в монго нет. Да, могут быть какие-то узкие места, в которых монго вырвет вперёд - например: одновременная запись однотипных документов. Но на типовых задачах монго/не монго - похеру.

Но на типовых задачах монго/не монго - похеру.

джойны! acid!

Что джоины? :) Джоины нужны, джоины за меня собирает ORM, я джоины не писал лет 8 уже. То же с монгой: там все данные иерархически вкладываются в объект, и не нужно скакать и собирать данные из 2-ух разных мест. Короче, вопрос в архитектуре данных, её нужно просто перевести в иерархическую. Мне подход реляционных не очень нравится - всё есть запись. Это хорошо для бухгалтерии, но не для современного веб.

Это хорошо для бухгалтерии, но не для современного веб.

В том-то и оно, что кому-то и бухгалтерия нужна, а её на MongoDB не сделаешь.

Не повторяй эту утку, ничего оно не заменяет. Почитай доки, возможность хранить json - это 1% фичей монги.

1. ACID нужен для сохранения связанных данных. Mongo можно применять если у тебя нет связей между сущностями. Если эти связи есть монга не для тебя.

2. В монге у тебя все выборки на совести приложения - крутись как хочешь.

3. Потому что эту часть сделали частью основного функционала. С нормальной БД тебе бы пришлось настраивать репликацию.

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

Возьми в руки англорусский словарик. Сразу половина слов тебе станет понятнее - таких глупых вопросов возникать не будет.

из 2-ух разных мест

предлагаешь хранить всё в одном месте (одной записи), и на каждый селект вытягивать терабайты данных, чтобы потом часами копаться в этих терабайтах в поисках нужной информации?

за меня собирает ORM,

что за ORM такой, который хорошо работает? Всегда настолько хорошо работает, что не нужно писать SQL, чтобы не получить просадку по производительности в 100 и более раз?

джоины за меня собирает ORM

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

но не для современного веб

что такое современное веб?

а транзакции кто для тебя собирает?

Тоже ORM. Уже года 3-4 как все мои orm поддерживают транзакции. Руками надо писать код, кода не много. Многопоточно работает тоже окей.

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

Предлагаю для поиска использовать специальные поисковые движки. Lucene, Sphinx, http://www.elasticsearch.org/.

что за ORM такой, который хорошо работает?

SqlAlchemy, http://ponyorm.com/, Django ORM. Нет, просадок не замечено. В среднем ORM отрабатывает 3-5 мс. У меня template (View) может рендериться дольше, особенно в Django.

что такое современное веб?

Это платформа, основанная на html5/Webkit, javascript/v8, svg, много графики и видео, преимущественно визуальная составляющая информации в сети, а также музыки в .aac/.mp4, социальная составляющая всех сервисов, хранение данных пользователей в облаке (в пуле серверов).

а, ну понятно, у тебя такая область специфическая.

Почему специфическая? Я уверен, большинство веб-разработчиков работает с html/javascript/node.js/django.

возможность хранить json - это 1% фичей монги

Странно, а я думал, что БД нужна в основном для хранения данных и их извлечения/изменения с помощью запросов.

Индексы по полям json (в т.ч. по произвольным выражениям, зависящим от полей документа) в постргресе тоже поддерживаются

если делать информационные сайты - наверное. У меня вычисления, аналитика, статистика, сбор этой фигни - время тратящееся на них (например, какой-то репорт типа «выведи мне статистику лучших игроков за танк Т-34» или «дайте все транзакции россия-беларусь за 2014 год, пожалуйста») может занять часы - совсем несопоставимо по порядку величин с отрисовкой вьюхи

большинство веб-разработчиков работает с html/javascript/node.js/django

node.js? django?

то-то все вакансии на hh хотят PHP xD

Ага, и Дельфи. Раша-бизнес. Для аналитики есть java elasticи всякие и си-расширения для питона. У нас тоже на проекте есть машинное обучение и искуственный интеллект, но морды то нужны в браузере ;)

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

filter/map/reduce спасают от джоинов

PS но таки MEAN стек очень плох.

Чем он плох?

http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/

Вопрос с дивана

Ответ с дивана: почитай про CAP-теорему, посмотри где монга, а где постгря в этом треугольнике. Выводы сделаешь самостоятельно.

а вот пропробуй на диване mysql 5.6

Дельфи

Оно еще до сих пор есть? Лет десять назад запомнилось как один препод сказал: если сделать то-то и то-то, то оно и не видно, что программа сделана на делфи.

http://www.mongodb-is-web-scale.com/

https://aphyr.com/posts/284-call-me-maybe-mongodb

http://www.quora.com/Which-companies-have-moved-away-from-MongoDB-and-why/ans...

1. Что именно из ACID не соблюдается, для каких веб-сайтов это не важно, а для каких ACID нужен?

ACI поддерживается на уровне 1 документа в 1 коллекции. В монге нет транзакций, поэтому случай для SQL транзакция-insert-update-delete-стоп в монге невозможен. В ее случае это будет три разных операции, если в момент между insert-update-delete произойдет чтение данных другим процессом, то он увидет, скажем свежий insert, но не увидет update и delete. Эту проблему решили ребята в форке TokuMX, там есть поддержка транзакций.

2. Как жить без джоинов?

Костыли на внутреннем JS. Не следил давно за MongoDB, но в 2.4 это было далеко-далеко от понятия PL/SQL. Т.е. что-то можно делать. На выходе получаем процедуру, которая делает map-reduce (возможно, в из нескольких запросов подряд в разные места) и отдает документы в нужном формате.

3. Почему MongoDB лучше скейлится?

By design. В частности мастер-мастер, реплики, арбитер все сделано из коробки. Минус в том, что эти процессы, как и отсутсвие транзакций приводят к одному и тому же побочному эффекту: все происходит асинхронно и поэтому приложение должно «понимать», когда что-то не так (например, insert в другую коллекцию только производится и надо подождать/отклонить запрос/т.п.

Т.е. что-то можно делать. На выходе получаем процедуру, которая делает map-reduce и отдает документы в нужном формате.

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

если джойн длинный

Длинные джойны оставь для SQL. Для NoSQL длинный джойн означает кривую архитектуру данных. И не надо говорить, что ты боишься увеличить объем документа или дубликации данных. Как раз таки, в идеальном случае структура данных должна ложится в один документ в одной коллекции. Тогда и выборки будут простыми. ИМХО.

У моей девушки брательник работает дельфином в Питере. Кодит всякую муторную аналитику, но сейчас их всех сокращают мухаха! Я так понял с его слов, что в Питере Дельфи рулит и педалит!

в идеальном случае

Да, все мы знаем, что hello world это идеальный случай для монги, или туду лист, или убийца твитора, гг.

By design. В частности мастер-мастер, реплики, арбитер все сделано из коробки.

Все же «master-master» репликации в MongoDB нет(https://jira.mongodb.org/browse/SERVER-2956). Riak не пробовал, Cassandra как раз умеет для определенного запроса выставлять дата консистенси(http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_config_...)

Минус в том, что эти процессы, как и отсутсвие транзакций приводят к одному и тому же побочному эффекту: все происходит асинхронно и поэтому приложение должно «понимать», когда что-то не так (например, insert в другую коллекцию только производится и надо подождать/отклонить запрос/т.п.

Это не так. CAP теорема говорит, что обеспечить даже ACID можно, но придется жертвовать остальными буквами ;)

Для NoSQL длинный джойн означает кривую архитектуру данных

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