Изучение mongodb

Будет профит, если ты будешь воспринимать её как документное хранилище жирных json, и поиск по ним. Всё. Не надо особо мудрствовать. Есть ещё ArangoDB, CouchDB - последний уделывает монгу по всяким мастер-мастер репликациям и надежности, но слегка проигрывает по скорости, есть и другие NOSQL - все нужно тестировать на своих «юзкейсах»

Странноватые какие то вопросы…
Вас заставляют юзать монгу и вы не можете определиться как с ней работать?

Данные могут хранить целиком корень агрегации при DDD подходе.

Если у вас на столько круто в плане архитектуры, что вы юзаете DDD то должны бы знать, что решение о выборе БД стараются максимально откладывать, что бы в момент принятия решения обладать максимально точными требованиями к фичам.

А вы как будто наоборот разработку от базы начинаете.

Честно сказать, я второй способ с потолка взял. Вопрос больше из праздного любопытства — придумать хороший способ использования возможностей монги. Сам я использовал монгу по своей воле, как сказано выше, тупо как хранилише жирных json-ов. На паре проектов видел как ее юзают вместо нормальной БД. Только примитивные поля, мастеря руками джоины и т.д.

К вопросу DDD, может холивар быть, ЕМНИП, но изначально у Эванса в книжке изложение плясало от БД, это потом фанаты Мартина чистую архитектуру притянули, типо база где-то во внешнем слое находится.

К вопросу DDD, может холивар быть, ЕМНИП, но изначально у Эванса в книжке изложение плясало от БД, это потом фанаты Мартина чистую архитектуру притянули, типо база где-то во внешнем слое находится.

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

У меня в голове они отлично дополняют друг друга.

типо база где-то во внешнем слое находится.

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

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

Дык! Ведь зря так делали.

Возможности монги в кластерности и шардировании «из коробки». Вот не влезаешь ты по данным или по запросам после всех кэшей в один сервак - рассмотри монгу.

Есть определенные плюшки при эксплуатации в schemaless, но это оборачивается обработкой дополнительных кейсов в коде работы с такими данными.

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

С доктриной в принципе работать приятно и про производительность там в общем-то думали, но есть печалька с тем что она написана под старый драйвер монги, полифилл работает, но жрет проц на преобразование типов( по опыту работы с монгой из go там тоже десериализация данных при выборке больших объемов данных это одно из горячих мест). Ещё нужно быть аккуратным с референсами, иногда они не так эффективны как хотелось бы( порождают много запросов там где можно было бы обойтись меньшим количеством). Есть грабли с утечкой через реестр загруженных из базы объектов. Это когда нужно обойти скриптом коллекцию с каким-то миллионом объектов, в память они все не влезут, поэтому делаешь выборку чанками извлекая из базы за раз какое-то приемлимое количество документов. Запускаешь, а скрипт все равно со временем выжирает память и падает. А все потому что внутри доктрины хранится хэш со всеми извлечёнными из базы объектами. Приходится сооружать костыль с сбросом его после обработки каждого чанка данных.

http://rsdn.org/forum/flame.comp/7204911.1

Ну и до кучи ещё две мои закладки из того же обсуждения:

http://rsdn.org/forum/flame.comp/7206778.1

http://rsdn.org/forum/flame.comp/7205375.1 (топикстартер, рассказ про Amazon)

Все же есть разделение труда. Кто-то делает MVP-шки за неделю, кто то проектирует годами. Стартаперу создающему прототип достаточно представления данных в БД как json и незнание проблем масштабирования. MERN и MEAN разработчики же востребованы. Виноват выдающий на разработку деньги, если он думает, что исполнитель клепающий систему за неделю в одиночку может сделать что-то надежное и долговечное. Увольнение MERN разработчика за некомпетентность в архитектуре, в таком случае, похоже на сказку дядюшки Римуса про Братца Кролика и терновый куст.

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

Стартаперу создающему прототип достаточно представления данных в БД как json и незнание проблем масштабирования.

Всё же редко какая бизнес-логика обходится без джойнов, а делать их руками при прототипировании – тот ещё бред. Поэтому в контексте обсуждения, на которое я накидал ссылки, я бы сказал, для прототипа достаточно SQL. А вот дальше, если начинаются сверх-нагрузки, тут и подтягиваются супер-профи. Там по ветке где-то говорилось, что они переписали всё на NoSQL после того как в очередную чёрную пятницу лёг самый дорогущий в мире SQL-кластер (то ли что-то оракловое, то ли DB2… лень искать).

Но джоины нужны если мы нормализовали структуру БД, а нормализуем мы потому что

1. Привыкли думать в категориях реляционных отношений
2. Хотим заранее оптимизировать запросы

Например, мы разбили предметную область на относительно независимые домены. Мы уже знаем что авторы книг у нас всегда будут добавляться и запрашиваться с книгами, информация об авторах мизерная и несущественная, то всю информацию об авторах мы можем хранить в домене Book. Если заказчик придумает, что хочет добавлять информацию об авторах отдельно от книг, то тогда и будем создавать отдельный домен Authors со своей бизнес логикой создания автора.

Не забываем что мы делаем прототип. У прототипа обычно несколько целей:

1. Чтобы заказчик в процессе руководства созданием прототипа построил себе ментальную модель товара. Потому что изначально он слабо представляет реализацию.
2. Маркетологи провели исследования и тестирования и нашли потенциальный рынок.

Основная оптимизация на данном этапе - это время сдачи MVP.

Потом заказчик захочет

1. Добавлять фичи в прототип, чтобы выйти на серьезный рынок.
2. Чтобы фулстек продолжал поддерживать ту галиматью, которую он написал вместе с заказчиком.

Это уже шиза заказчика.

Это уже шиза заказчика.

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

К сожалению я так не могу похвастаться, что я идеальный исполнитель и никогда не ошибаюсь :)

Да при чём тут ошибки-не ошибки? Писать прототип, особенно если на другом языке, – это гарантия что на выброс. А если минимальную инфраструктуру поднять сразу, то дальше проект пишется в обычном режиме, пофиг что сначала минимальный прототипный функционал, а потом постепенно наращивается: любые архитектурные косяки, возникающие как следствие разрыва между прототипом и полнофункциональной вещью, разруливаются рефакторингами.

Кроме прочего, это ещё и надёжнее. Кто-то из гуру (наверное Буч или Брукс) говорил, что большая работающая система всегда получается из маленькой работающей системы; большая система, целиком спроектированная на бумаге, никогда не заработает. А прототипирование как раз создаёт разрыв гораздо больший, чем если ползти от маленькой системы к большой через рефакторинги.

У меня была ситуация, когда компания хотела один проект, потом на его основе другой проект, а потом на его основе третий, потому-что надеялась, что одно из трех выстрелит. Вот мне представляется, что в такой ситуации, чтобы разработчик не сгорел на рабочем месте, приходится минимально уделять внимание, нормальным фундаментам и прочим оптимизациям. Сейчас рассматриваю MERN или MEAN стек для таких кейсов.

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

Оптимизациям – может быть. Но совсем тяп-ляп нормальный спец делать не способен физически. Пару раз приходилось увольняться ровно из-за индивидуальной непереносимости говнокода. С другой стороны, применительно к твоим словам – без знания, что там конкретно были за задачи, с моей стороны это обсуждение сферического коня в вакууме. Так что хз.

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

1. С одним разработчиком координация во время создания прототипа происходит быстрее чем с командой.
2. Один разработчик делает полностью бекенд, фронтенд, девопс.
3. Невозможно быть спецом по всему, поэтому выбираем js
4. Монгу выбираем потому что она дружелюбна к js и потому что в монге мы можем практически хранить структуру json который через эндпоинты гоняем.

Получаем MERN разработчика.

Сначала постгрес, потом постгрес с колонками и Json, потом миграция на Greenplum какой-н будь или добавление кликхауса...

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

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

Сам не сталкивался, но звучит как частное проявление того факта, что RDBMS – это ACID из коробки, а NoSQL – кирпичик для самопальных решений. Т.е. с ним в принципе надо быть и умнее, и осторожнее.

монга официально ACID с какой то версии, только этот ACID вообще толком ни о чем не говорит, это как UNIX-like в наше время, вроде как смысл какой то есть но один хрен фряха линукс и мак это разные операционки с огромным количеством отличий.

монга официально ACID с какой то версии, только этот ACID вообще толком ни о чем не говорит,

Угу, слышал. Что оно там якобы есть, но по факту коцаное. И не только в монге.

Что оно там якобы есть, но по факту коцаное.

В том то и дело что сам ACID так сформулирован что от него никакого толку. Так что в монге самый настоящий ACID. Но ему пора бы уже на пенсию.

Я просто у себя в голове не могу представить ситуации в которой можно было бы использовать ACID как аргумент при выборе БД.

Ну типо, сидим мы такие, обсуждаем разные БД, их фичи, у нас есть листок с обязательными требованиями…. и тут вдруг кто то встает и говорит: «Подождите, но ведь монга это ACID!» …. и что?

Изучение mongodb (комментарий)

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

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

Вот, если все в мире забудут что такое ACID ничего не изменится, потому что то что там написано и так очевидно, а в 1980 было не очевидно и имело смысл.

Ну и вообще, монга прославилась тем что херит данные но она ACID)

Там все правильно написано только ACID для этого не нужен)

Без комментариев.

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

Разумеется система в целом. Об этом везде и речь.

Вот, если все в мире забудут что такое ACID ничего не изменится, потому что то что там написано и так очевидно, а в 1980 было не очевидно и имело смысл.

ну вот например I, это пофикшено, сильно очевидно?

https://blog.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827

Ну и вообще, монга прославилась тем что херит данные но она ACID)

данные не похерены, но результат запроса неверен.

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

То что написано в статье имеет смысл, то что разработчики сообщили что монга это ACID не имеет смысла.

https://www.mongodb.com/basics/transactions

Вот, они этот ACID прям здоровыми буквами как трофей повесили в заголовке, а толку то? Автору статьи помогло?

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

А лол, там 2016 год, не обратил внимание, это не мое мне подкинули.

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

так оно работает в 4.0+ ?

почитал доки, там some situations, что-то сложно все описано как-то.

https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/#cursor-snapshot - это оно?

Честно говоря монга наверное вполне может быть «дефолтной СУБД» когда не знаешь что тебе нужно

Когда не знаешь что нужно от базы бери постгрес 😄 Монга всё-таки nosql и отличие не только в языке запросов, но и в отказе от acid, что может сделать больно в какой-то момент, если привык думать в парадигме rdbms

Не работал с 4.0+, увы

но и в отказе от acid

https://www.mongodb.com/basics/transactions

MongoDB supports multi-document ACID transactions as of version 4.0, even across replica sets and sharded clusters.

Когда не знаешь что нужно от базы бери постгрес 😄

+1