Кажется. Какие аргументы были реальные? Mongodb имеет не sql синтаксис запросов. Ну и? Это не + или -. Вкусовщина. Ну далее - она не даёт гарантию записи. Ну она не всегда нужна + можно сделать чтобы точно записала... Все аргументы очень аргументые и ничего не имеют общего с реальным опытом спорщиков. Так, лозунги фанатов данной
СУБД.
Причем посмотрите - я не сказал что PGSQL лучшая, а только утверждаю что на моих задачах она отлично подошла и что большинство задач реляции можно представит в виде nosql.
Но признать это - значит усомниться в величии слоника. Что как бы не комильфо. Простите, но ад таким не стебать нельзя.

/report

Yaroslav Schekin: @afiskon @confguru @Komzpa @pasha_golub @obartunov

Модераторы, можно объяснить человеку, что с переходом на личности нужно как-то завязать?

Ребят. Так сам кикнусь. На самом деле разочарован в сообществе. Всем добра :-)

ад какой, пойду exadata  лучше куплю 🙈

Моё личное имхо - nosql (как бэ) возможности у пг точно будут развиваться. Как и у всех игроков рынка. И народу в любом случае придётся более гибко оценивать ка возможности так и и обоснованность их применения в тех или иных ситуациях. Без комментов плз:))

Да ну нельзя же сделать. Ну она ломает данные by design и всё тут. Ну вам повезло и пока не сломало ничего. Вырастет нагрузка, вырастет concurrency - сломает. Ну есть же более пригодные NOSQL штуки, тот же elastic для полнотекстового поиска, есть cocroachdb, умеющий в json и прошедший jepsen. Но  не монга. Монга это 90% маркетингового буллшита и 10% реально работающего. Я вообще не знаю никого крупнее очередного стартапа, реально использующего монгу в продукте.

вам напомнить про маленького мальчика и голого короля, который
не правил ни одного дня за жизнь?

>Сам юзаю пг, который притворяется монгой
это где ж так вы слона то не любите?

а можно ссылочку где это было озвучено?
я просто и близко такого не встречал.

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

> Ну далее - она не даёт гарантию записи. Ну она не всегда нужна
мне больше не наливать, я к монге на пушечный выстрел не подойду.
Действительно зачем в СУБД ACID,пусть будет ACI,AC,A.... :)

По идее вот

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

понравился комментарий к докладу.
>Причем, тут молодые слова и так далее. MongoDB используют, не из-за маркенгово хода, а по многим другим причинам, на пример то, что java разработчик может писать не переходя на старый язык и медлительный SQL.
много думал, что я делал не так на java с pg. :)

Каждый раз, когда слышу про медленные реляционки, начинаю грустить. До сих пор ни разу не попалось ни одной ситуации, где сообразно задаче выбиралась какая-то из распространенных реляционок и дело доходило до ситуации "вот не хватает её производительности и всё тут. Вообще ничего не сделать". Жизнь пролетает мимо(

У них же там ACID с версии 4.0 (одноузловый, с весрии 4.2 многоузловый).

Только буковка I  - немного не та I, которая в PG возможна (не SSI). Хотя должна удовлетворять SI. Кажется, в моих задачах всегда хватало SI.
И, судя по тестам jepsen, SI не гарантирован пока что (я так понял, что там просто баги разработчиков, связанные с повторами, поправьте, если не так).

Я работал с mongodb, когда были весрии 2.*. Те версии отбили всё желание иметь с этой базой что-либо общего, потому что рано или поздно нужны были транзакции, приходилось их там реализовывать из приложения.

Как пользователя этой БД мне не нравилось следующее:
1. отсутствие схемы (попробуйте написать там запросы, который сделает хоть что-то хотя бы тривиальное, когда у вас внезапно в поле хранится строка, массив, objectId, null)
Да, там вроде в версии 3.* добавили ограничения на тип и можно даже схему указать (поправьте, если не так).
2. отсутствие join-ов.
Да, где-то в 3.* добавили join-ы по object_id, но в жизни не всегда так приходиться join-ить.
Если вы думаете, что хотеть join-ить в mongodb - это неправильно продуманная схема, то вы ошибаетесь, когда посмотрите на максимальный размер документа. Он не является неограниченным.
3. монструозность запросов
Попробуйте написать нетривиальный запрос в mongodb и потом такой же запрос в postregsql. Разница на лицо.
У меня в pg были запросы на 3 экрана, думаю, что в mongodb написать аналогичный  запрос - это всё равно, что написать книгу (да, преувеличиваю, но иначе читать скучно 😊).
4. отсутствие транзакции
Несколько раз думал, что транзакции не нужны в проекте и брал эту БД, но проект растёт, изменяется и рано или поздно они нужны. У меня было так 2 раза.
Да, в 4.* их добавили. Да, там баги есть, но это потому что транзакциям года 1.5-2 жизни. Скорей всего те гарантии, которые дают в mongodb мне бы хватило, это потому что у меня проекты такие. Совершенно точно понятно, что это далеко не для всех.

Кто знает кейсы использования этой СУБД?)

Из кейсов: хранение кэша. Без какой либо логики. ВСе данные о пользователях хранились как правило в бд рядом. Например, мускул или постгрес. Монго использовали только как хранилище кэша, который не страшно потерять

Для кеша использую memcached и redis.