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

добрый день. Такая ситуация. Есть mongodb на легаси проекте, я хочу в ней немного порядок навести, но я не спец по монге. Обнаружил там такое: используются в одной базе и в одних и тех же коллекциях одновременно и обжект айди и стринговый uuid. У одного документа в коллекции может быть uuid, у другого обжект айди "_id" : ObjectId("62a99f2eb783269f99911bf1"), "_id" : "88f90158-85b3-4515-b123-8f9b025e3aba" Вопросы: 1. Стоит ли по этому поводу беспокоится? 2. Чем это чревато? 3. Какие стоит принять меры? Спасибо.

а проблема то в чем? зачем в монгу полезли?

это легаси проект. Теперь эта база - моя ответственность. Просто хочу разобраться. 1. Стоит ли по этому поводу беспокоится?

вопрос все тот же, проблемы есть с БД? если нет то не стоит

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

:) я боюсь, что будут 😅 потому решил спросить

не понял вопрос, допустим oplog вмещает 1 час (день, неделю...), пусть сейчас 13:00, значит мы можем начать чтение из прошлого вплоть до 12:00. Чтение остановилось, оплог продолжает расти и доступная дата сдвигается. Снова готовы читать в 13:30, а значит потенциально доступное время с которого можно продолжить чтение 12:30. Теряем данные с 12:00 до 12:30 и это сильно лучше, чем начать читать с 13:00

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

в теории так и есть, но жизнь бывает другая

привет, подскажите пж, можно ли переназначить дефолтный порт подключения mongosh ? именно порт, по которому монгош подключается к базе, чтоб не указывать его каждый раз через --port)

Добрый день, в mongo compass можно как-то увеличить число воркеров когда импортируешь json файл(3gb)? Чтобы он быстрее выполнялся

отличные курсы у самой монги

Но вопрос - как получить этот индентификатор обратно?

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

Вроде стандартный

А, понятно. Ну, а как из него данные получить?

Использую mongoose-sequence для генерации seq Если происходит отклонение транзакции внутри withTransaction, то в коллекции counters (от mongoose-sequence) происходит увеличение счетчика словно транзакция была успешно добавлена Можно ли как-то избежать увеличение каунтера при отклоненной транзакции? (node js + mongo)

судя по гиту https://github.com/ramiel/mongoose-sequence транзакций не поддерживаются, плюс оно уже заброшено и не стоит ее использовать. В любом случае вопрос, зачем вам автоинкременты и уж тем более зачем вам честные без пропусков?

В моей игре seq помогает упростить разработку и отслеживание ходов игроков. При использовании корректно увеличивающихся seq номеров, все идет по порядку, что придает уверенности в правильной работе приложения. Когда видишь, что игра имеет номер 100, это гарантирует, что в базе данных тоже есть игра с номером 100 и игр точно 100, – это избавляет от необходимости дополнительных запросов для подсчета игр и упрощает интерфейс для вывода номеров игр. Иногда seq также является удобным параметром для поиска, особенно там, где ограничения по символам делают _id менее удобным выбором.

В данном кейсе, так понимаю, из-за устаревшего mongoose-sequence, и желания "железобетонно" проставлять инкременты – это обновлять вручную через findOneAndUpdate внутри withTransaction с другими запросами?

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

А что в них плохого?

Всем привет. Наверняка кто то решал подобную задачу. Есть коллекция с задачами. Несколько воркеров работают паралельно. каким образом можно решить проблему со множественным обновлением статусов задач (чтобы разные воркеры не работали над 1 задачей)

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

понимаю что вопрос глупый. как понять удалось поменять статус или нет. я делаю так. выбираю пул задач через find и меняю статусы update_many. как я знаю статусы поменяются везде.

Атомарный доступ к коллекции, задаче. Выставление в документе id воркера или ещё какой механизм

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

Если в slowest operations операция выполняется 15 секунд, а через агрегацию за 11 мс - это из-за нагрузки на БД в моменте? Или какие причины?

получается это подход не работает с update_many

да, задачи с race condition решаются либо локами либо атомарными лок фри, на монге по факту нет локов в традиционном понимании и их надо городить самостоятельно либо через доки с версиями, либо через транзакции и обработки ошибок на них. Так что остается лок фри аналоги на атомарных findAndUpdate

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

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

например я бы для реализации очереди не брал бы БД, в которой нет функционала очереди, а взял бы менеджера очередей и на нем построил

недавно смотрел ролик где обсуждался подход, как раз про паралельную работу https://youtu.be/oVgZUYN_7s0?t=1196 . но не получилось реализовать

главный коммент под видео Мрак... Мир авито, в котором не придумали MQ брокер. что намекает на подход к решению проблемы

скорее всего он имел ввиду как раз одиночный update

и в результате будет кол-во обновленных данных?

недавно смотрел ролик где обсуждался подход, как раз про паралельную работу https://youtu.be/oVgZUYN_7s0?t=1196 . но не получилось реализовать

досмотрел, и второй же вопрос из зала о том чего не заиспользовали ту же кафку)

глянул эту секцию, там про updateMany, просто в нем в условия идут $or: [ {услвоие для одного дока}, {услвоие для одного дока}, ]

у меня другой вопрос. допустим я хочу поменять 100 задач. а мне в modified_count вернет 80. как понять какие доки я поменял? чтобы мог вернуть обратно статус для них

сделать еще один запрос и вытащить те которые поменялись

так. снова вопрос. я сделал выборку по статусу и получил 100 задач. поменял через $or статус и получил что поменялось 80 задач из 100. я понял что кто то другой взял в работу 20 задач. какой запрос мне сделать чтобы получить 80 измененых мной задач

в апдейте надо указать id воркера, соответственно надо будет выполнить запрос с фильтром который был (тот $or большой) and id воркера