Etc/hosts хорошая практика :)

Не очень... Хорошая практика днс.

Всем привет! Пытаюсь разобраться, как работает MongoDB в кластере. Имеется два web сервиса (две копии одного и того же сервиса), которые общаются с MongoDB: writeConcern: 1, readConcern: local, read preference: primary. Клиент (браузер) шлет два последовательных запроса (второй ждет окончание первого). Первый запрос на запись, второй на чтение. Может ли быть ситуация (не рассматриваем кейсы выбора нового лидера), когда второй запрос не получит изменения первого запроса? К примеру, как отработает в кейсе, когда первый запрос прилетит на первый web сервис, а второй - на второй?

Всем привет! Пытаюсь разобраться, как работает MongoDB в кластере. Имеется два web сервиса (две копии одного и того же сервиса), которые общаются с MongoDB: writeConcern: 1, readConcern: local, read preference: primary. Клиент (браузер) шлет два последовательных запроса (второй ждет окончание первого). Первый запрос на запись, второй на чтение. Может ли быть ситуация (не рассматриваем кейсы выбора нового лидера), когда второй запрос не получит изменения первого запроса? К примеру, как отработает в кейсе, когда первый запрос прилетит на первый web сервис, а второй - на второй?

а зачем 2 запроса? 1 не может вернуть что записал?

Если ждет ответа, то такого не случится

А клиенты не используют какую-то версию базы, которую используют при каждом запросе? Насколько я понимаю, там используется MVCC

Какая разница если у вас запросы не одновременные

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

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

А как-то клиентские сессии используют этот номер версии?

Всем привет! Пытаюсь разобраться, как работает MongoDB в кластере. Имеется два web сервиса (две копии одного и того же сервиса), которые общаются с MongoDB: writeConcern: 1, readConcern: local, read preference: primary. Клиент (браузер) шлет два последовательных запроса (второй ждет окончание первого). Первый запрос на запись, второй на чтение. Может ли быть ситуация (не рассматриваем кейсы выбора нового лидера), когда второй запрос не получит изменения первого запроса? К примеру, как отработает в кейсе, когда первый запрос прилетит на первый web сервис, а второй - на второй?

https://www.mongodb.com/docs/manual/reference/read-concern/#real-time-order

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

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

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

Всем привет. Вопрос такой: В mongodb можно ли primary key поле назвать по своему, а не _id?

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

через findAndUpdate можно сделать

Как можно найти документ по его свойствам его вложенного документа ?

через точку путь собираете find({ r.lvl1.lvl2: "val" }) работает и с массивами

Спасибо. А не подсажите ли еще может ил быть причиной ошибки то что я пытался этот запрос создать как метод дял модели? categories.methods.getServices = function () { return Service.find({'category._id: this.id}) }

если это прям копипаста, то тут кавычка открывается и не закрывается

Всем привет. Я тут миграцию пишу, всё хорошо кроме одного момента В конечном итоге нужно чтобы у всех данных _id был с 1 по порядку Подскажите как это сделать? [ { "aggregate": "events", "pipeline": [ { "$project": { "_id": 1, "events": 1 } }, { "$unwind": "$events" }, { "$project": { "_id": 0, "aggregate_id": "$_id", "event_type": "$events.event_type", "data": "$events.data", "timestamp": "$events.timestamp", "aggregate_type": "$events.aggregate_type", "version": "$events.version", "metadata": { "position": "$events.version" } } }, { "$out": "new_events" } ], "cursor": {} } ]

Если делать сортировку по _id то база данных возвращает документы по времени создания в порядке. Для этого { $sort: {_id: 1} }

Не) по умолчанию там ObjectID (по моему, не особо силен в mongo) А нужно чтобы были простые числа

Всем привет. Я тут миграцию пишу, всё хорошо кроме одного момента В конечном итоге нужно чтобы у всех данных _id был с 1 по порядку Подскажите как это сделать? [ { "aggregate": "events", "pipeline": [ { "$project": { "_id": 1, "events": 1 } }, { "$unwind": "$events" }, { "$project": { "_id": 0, "aggregate_id": "$_id", "event_type": "$events.event_type", "data": "$events.data", "timestamp": "$events.timestamp", "aggregate_type": "$events.aggregate_type", "version": "$events.version", "metadata": { "position": "$events.version" } } }, { "$out": "new_events" } ], "cursor": {} } ]

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

да я уже сприпт на Go написал, надо было так сразу сделать)

Groups.find(query, null, { skip, limit, sort: { name: 1 }, }).populate({ path: "users", match: { verified: 1 }, }); Кто-то может подсказать, как можно это оптимизировать, в какую сторону смотреть? С популейтом тестовый запрос выполняется 3сек, без него 300мс.

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

Всем привет Есть вью агрегация , есть поле тип(int), надо заменить его на соответствие из словаря types = {1: "type1", 2: "type2"} Как это можно сделать?