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

Я делаю запрос к базе: запрашиваю документ, вместе с этим выполняю Populate (как Join в реляционных базах) к другой коллекции. C populate варианта 2: либо мне вернется документ (если найден), либо null (если не найден). Вопрос не столько к монге относится, сколько концептуальный (или даже архитектурный). Как обрабатывать случай, если populate возвращает null? Например, у меня HTTP GET запрос - запрос пользователя (users) по ID. В документе users есть поле role, по нему я выполняю populate. Возвратить пользователю я должен структуру с данными users, которая включает в себя так же и populated документ role. Но вот незадача - он null. Мне просто интересно, ведь в реляционных базах данных такое должно встречаться постоянно. Неужели разработчики каждый раз создают отдельную ошибку в таких случаях? Или как вообще это обрабатывается?

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

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

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

Я делаю запрос к базе: запрашиваю документ, вместе с этим выполняю Populate (как Join в реляционных базах) к другой коллекции. C populate варианта 2: либо мне вернется документ (если найден), либо null (если не найден). Вопрос не столько к монге относится, сколько концептуальный (или даже архитектурный). Как обрабатывать случай, если populate возвращает null? Например, у меня HTTP GET запрос - запрос пользователя (users) по ID. В документе users есть поле role, по нему я выполняю populate. Возвратить пользователю я должен структуру с данными users, которая включает в себя так же и populated документ role. Но вот незадача - он null. Мне просто интересно, ведь в реляционных базах данных такое должно встречаться постоянно. Неужели разработчики каждый раз создают отдельную ошибку в таких случаях? Или как вообще это обрабатывается?

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

+ это можно выводить и через другие структуры с мониторингом

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

Привет всем Возникла проблема: MongoDB не использует созданные индексы при сортировке Есть индекс count_-1, выполняю .sort({count: -1}), в результате запрос выполняется долго и в статистике использования индекса его кол-во не прибавляется В чём может быть дело?

Дело скорее всего в том что в выборке это поле не используется

в фильтре (первый параметр)? да, не используется. получается, никак не ускорить сортировку?

Составной индекс может помочь, но не факт если выборка широкая

знает ли кто канал/чатик с вакансиями по Монго и/или иными nosql?

hh

Пытаюсь использовать оператор $ в проекции, чтобы вернуть подходящий элемент во вложенном массиве: https://mongoplayground.net/p/6CMYQC4phSi При этом возвращается весь элемент массива Services. Подскажите, как сделать, чтобы в нём был только тот элемент массива Prices, который подходит под условие (у которого Id равен 3)?

Проекции по вложенным массивам к сожалению так не работают, так как они возвращают первый совпавший элемент, в вашем случае это { "Name": "Service 2", "Prices": [ { "Id": 3 }, { "Id": 4 } ] }

Это я уже понял. Но мне нужно уменьшить количество возвращаемых данных. Только аггрегацией?

Это я уже понял. Но мне нужно уменьшить количество возвращаемых данных. Только аггрегацией?

Если задача просто ограничить данные то и limit подойдёт

Не подойдёт. limit ограничивает количество возвращаемых документов. А мне нужно уменьшить размер самого документа, потому что в Prices на самом деле приличное количество элементов, которые не хочется гонять по сети. Поэтому, видимо, аггрегация 🤷‍♂

Всем привет. Подскажите пожалуйста можно ли настроить replica set из трех нод так, чтобы при падении двух из них можно было писать в последнюю, оставшуюся? Write concern я принудително выставил в w:1, а вот как перевести оставшуюся ноду из secondary в primary не нашел. Спасибо.

Всем привет. Подскажите пожалуйста можно ли настроить replica set из трех нод так, чтобы при падении двух из них можно было писать в последнюю, оставшуюся? Write concern я принудително выставил в w:1, а вот как перевести оставшуюся ноду из secondary в primary не нашел. Спасибо.

Нода осталась одна в secondary, изменить параметры кластера может только primary.

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

никакой магии, вы можете защититься только от потери (N-1)/2 нод, т.е. если у вас три ДЦ, то вы переживете только потерю одного из них

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

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

Звучит как идеальной случай репликации

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

Не получится это приведёт к сплит браину

Это да, но он не страшен для сервиса, будет достаточно если с мастера данные перезальются после восстановления

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

Это да, но он не страшен для сервиса, будет достаточно если с мастера данные перезальются после восстановления

он страшен для состояния кластера, а не для вашего сервиса

Тогда лучше востонавливать репликацию

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

Кластер в случае сплита как себя поведет, развалится?

Есть вариант поиграть с ha proxy и настроить зеркальность сообщений и ниже редис чтобы данные кэшировались

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

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

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

Даже если не критично это может плохо сказаться на остальных участках кода

очевидно что не нужен))

Задача скорее репликации чем отказоустойчивости в классическом понимании

Тогда и код не нужен пусть люди сами пишут запросы в базу чтобы получить их просто раздадим дрова всем клиентам)))

Тогда и код не нужен пусть люди сами пишут запросы в базу чтобы получить их просто раздадим дрова всем клиентам)))

Тогда при ЧП ставьте новую бд и записывайте реплики по новой с первого мастера

Спасибо всем!

Я не понял этот совет помог?

Когда найдете решение расскажите к каким итогам вы пришли, очень интересно

Если вы рассматриваете что больше половины нод могут быть недоступны, то может монга не ваш выбор. Посмотрите касандру