у вас монгус?

Ребят, всем привет, подскажите пожалуйста, возможно ли то, что я хочу сделать? Есть документ A, у которого есть поле networks - это массив объектов. Структура объекта: { currency: Types.ObjectId; amount: number; } На входе я имею некий массив values, структура которого аналогична полю networks Я хочу одним запросом .updateOne() обновить поле networks, прибавив каждому полю amount значение из принадлежащего ему объекта в поле values (определяется по полю currency).

Ребят, всем привет, подскажите пожалуйста, возможно ли то, что я хочу сделать? Есть документ A, у которого есть поле networks - это массив объектов. Структура объекта: { currency: Types.ObjectId; amount: number; } На входе я имею некий массив values, структура которого аналогична полю networks Я хочу одним запросом .updateOne() обновить поле networks, прибавив каждому полю amount значение из принадлежащего ему объекта в поле values (определяется по полю currency).

нечто похожее и еще с апсертом делал когдато https://t.me/mongodb_ru/132089 но очень не тривиально и тяжело потом сопровождать, проще вытащить в код, поправить и залить уже обновленный массив полностью

Звучит возможно, но ты хочешь всему полю networks добавить это значение или или выборочно

Ребят, всем привет, подскажите пожалуйста, возможно ли то, что я хочу сделать? Есть документ A, у которого есть поле networks - это массив объектов. Структура объекта: { currency: Types.ObjectId; amount: number; } На входе я имею некий массив values, структура которого аналогична полю networks Я хочу одним запросом .updateOne() обновить поле networks, прибавив каждому полю amount значение из принадлежащего ему объекта в поле values (определяется по полю currency).

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

Как это можно реализовать?

Всем привет! Подскажите, как считаете, в монго нормально реализованы транзакции и принципы ACID? ПыСы: документацию читал, все смотрел Но хотел бы узнать личный опыт Вопрос исследовательский, можно ли будет в дальнейшем полностью отказаться от реляционный бд в пользу nosql, где существуют ACID и транзакции Не кидайте камни, надо научную статью писать..

а конфликты возникают очень-очень часто. ну фактически, почти всегда. если в базу пишется что-то, операция записи же может выполняться много миллисекунд, и если паралельно идет запись в разных местах, то у тебя 100% возникнет конфликт максимум в течение нескольких секунд.

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

Понимаю, просто нужно про что то новое написать статью, а вот про что - хз.. RavenDB увидел, тоже NoSQL но с транзакциями

на научную статью это не тянет

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

Есть разные подходы в построении хранилищ данных больших систем, например в сфере ecom Стоит вопрос, использовать polyglot persistence, мультимодальную дб или придумывать, что то свое Как вариант был, это отказ от реляционнки в пользу nosql и тогда в первом подходе мы избавимся от одного вида БД -> уже что-то новое Научная статья не должна быть про великие открытия и то, как все у тебя хорошо получилось Открой semanticscholar и посмотри про что люди пишут, бывают статьи, которые пишут об одном и том же

Удаление аккаунта юзера с сайта выглядит как-то так... А в РСУБД это были бы связанные сущности, достаточно было бы удалить одну и каскадно бы удалились все с ней связанные. А тут придется еще возвращаться, что-то добавлять, если у тебя добавилась коллекция.

Удаление аккаунта юзера с сайта выглядит как-то так... А в РСУБД это были бы связанные сущности, достаточно было бы удалить одну и каскадно бы удалились все с ней связанные. А тут придется еще возвращаться, что-то добавлять, если у тебя добавилась коллекция.

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

Удаление аккаунта юзера с сайта выглядит как-то так... А в РСУБД это были бы связанные сущности, достаточно было бы удалить одну и каскадно бы удалились все с ней связанные. А тут придется еще возвращаться, что-то добавлять, если у тебя добавилась коллекция.

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

ох уж эти хлебушки не соблюдающие ACID...

что бы не пороть чушь, советую эту книгу, как минимум от корки до корки

я разрабатываю в основном сайты обычные. и для них монга не подходит. ну ее можно использовать (чем я и занимаюсь), но она просто не подходит, РСУБД бы подошла лучше. Но это не значит что ее нельзя использовать для того для чего она и создавалась.

Удаление аккаунта юзера с сайта выглядит как-то так... А в РСУБД это были бы связанные сущности, достаточно было бы удалить одну и каскадно бы удалились все с ней связанные. А тут придется еще возвращаться, что-то добавлять, если у тебя добавилась коллекция.

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

Прочитал немного, не от корки до корки, а того что касается транзакций в nosql, там так и пишут - в нем понятие acid не определено так же четко как в реляционных базах и под ним может подразумеваться что угодно. А в чем чушь? Что такое по сути монго? В нем нет модели. Просто набор коллекций, которые ты сам между собой согласуешь как хочешь, но никаким принципам это следовать не обязано.

Че за проект? Я делал 2 проекта. Тот который сейчас, еще относительно прост. Предыдущий был сайтом организации туристических походов и поиска попутчиков. Там какие-то тонны быдлокода приходилось городить чтобы базу поддерживать в согласованном состоянии. В реляционных бд надо было бы просто изначально продумать схему. Дальше поддержка согласованности бы обеспечивалась субд

Не надо удалять данные из БД. Надо помечать их удалёнными. Ну и внимательно думать над структурой. Да, надо садиться и проектировать. И да, подходы из реляцих БД не всегда напрямую применимы.

Тогда нужен бесконечный диск, а я же не Гугл. Если все это крутится на впс за 5 баксов в месяц

Модель есть всегда. Когда мне говорят, что монга "схемалесс", я груснею и иду искать другого собеседника. Схема описана в коде. Так и с РСУБД тоже схема описана и в коде тоже.

В моего даже нет понятия «внешний ключ», какая еще модель? Ну где-то на бумаге или в голове да, но субд о твоей модели ничего не знает и о том как коллекции между собой связаны, каждое действие по поддержке согласованности должно быть закодировано тобой лично в императивном стиле

Да. На уровне кода это прекрасно делается. Тебе не нужно делать это на уровне базы.

Делается. Но это дополнительный гемор, там где его могло не быть.

В реальной жизни его нет.

У меня был

Значит ты делал что-то неправильно.

Нормально делай, нормально будет. :-) А говорить, что монга для специальных кейсов, это крайне странно и как бы намекает, что тымне разобрался с тем, как с ней работать.

Можно сделать на монге все что угодно, но простой пример, я выше скрин кидал. Мы удаляем юзера. И есть еще десяток коллекций, в которых есть Id юзера. Сами по себе документы с идом этого юзера не исчезнут. Потому что схемы нет. Надо будет написать код удаления из каждой коллекции. И таких случаев в небольшом проекте может быть много. Пока ты просто добавляешь данные, все отлично. Но когда тебе надо их редактировать и тем более удалять, начинаются раздумья «а где еще в этот момент что-то может пойти не так»

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

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

Посчитай, через сколько времени это произойдёт. Доживут ли твои правнуки? :-)

Какой-нибудь ддос начнется или зациклится какая-нибудь хрень и все. И я исхожу из того, что бекенд должен одинаково хорошо работать как на супер-ЭВМ так и на одноядернике с гигом оперативки.

Преждевременная оптимизация. :-)

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

Когда начнется ддос на продакшне во время рекламной кампании будет уже поздно думать об оптимизации

Зачем сохранять весь запрос?

Это можно использовать для защиты от ддоса, чтобы понимать где точно робот.

Это не данные твоей бизнес-логики.

Инфраструктура отнимает больше половины времени и кода. Я не использую cms