Т.е. я не совсем понимаю как добраться до поля nestedField

Т.е. я не совсем понимаю как добраться до поля nestedField

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

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

А разве нельзя это проделать с помощью findOneAndUpdate?

на втором и далее уровне вложенности массива нельзя

на первом можно

Ахаххаа, я два дня искал решение, стеснялся сюда написать, т.к. это "тупой вопрос", а оказывается драссстье

А чё? Ну типа это ведь вполне обычный запрос должен быть...

А чё? Ну типа это ведь вполне обычный запрос должен быть...

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

А чё? Ну типа это ведь вполне обычный запрос должен быть...

вообще я тут слукавил, т.к. можно и на втором уровне, но тогда вы не сможете задать критерий для массива первого уровня и он обновит все подходящие объекты под критерий. Если он уникально идентифирует сущность только в одном массиве то можно https://www.mongodb.com/community/forums/t/mongodb-update-a-value-in-array-of-object-of-array/208302/3 но это редко когда надо

Подскажите плз, как обновлять вложенные массивы? Т.е. у меня есть "такая" схема данных: { _id: Object.Id obj: [{ _id: Object.Id field1: "bla-bla", field2: [{ _id: Object.Id nestedField: "blabla-bla }] }] И мне нужно обновить nestedField

db.collection.update( {"_id": "id"}, {$set: {"obj.$[i].field2.$[j].nestedField": "new value"}, {arrayFilters: [{"i._id": "i_id"}, {"j._id": "j_id"}] });

Должно вроде работать

db.collection.update( {"_id": "id"}, {$set: {"obj.$[i].field2.$[j].nestedField": "new value"}, {arrayFilters: [{"i._id": "i_id"}, {"j._id": "j_id"}] });

Я так пробовал уже. В итоге будет j недоступно, код ошибки 2, а текст badValue

Я так пробовал уже. В итоге будет j недоступно, код ошибки 2, а текст badValue

Хм... Значит облом

А если так? db.collection.update( {"_id": "id"}, {$set: {"obj.$[].field2.$[j].nestedField": "new value"}, {arrayFilters: [{"j._id": "j_id"}] });

Ща попробую :) Спс

А если так? db.collection.update( {"_id": "id"}, {$set: {"obj.$[].field2.$[j].nestedField": "new value"}, {arrayFilters: [{"j._id": "j_id"}] });

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

А если так? db.collection.update( {"_id": "id"}, {$set: {"obj.$[].field2.$[j].nestedField": "new value"}, {arrayFilters: [{"j._id": "j_id"}] });

Ооо, получилось

Ооо, получилось

Збс, буду знать что так можно)

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

Ну там вроде идентификаторы везде. Похоже на что то уникальное

Ну там вроде идентификаторы везде. Похоже на что то уникальное

хорошо бы если да, тогда решение подходящее)

Возможно ещё одна из проблем, это в параметрах поиска, я искал примерно так: {"_id": "id" "obj.field2._id": "docId" },

вообще есть мысли как сделать, но он громоздкий будет это update with aggregation где в агрегации с помощью фильтрации и жутких кондишнов делается мерж объекта. Теоретически должно работать, но сам не делал

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

Ну ведь я ищу по Id, которое не может быть продублировано

Ну ведь я ищу по Id, которое не может быть продублировано

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

стоп

Больше массивчиков внутри массивчиков

db.collection.update( {"_id": "id"}, {$set: {"obj.$[i].field2.$[j].nestedField": "new value"}, {arrayFilters: [{"i._id": "i_id"}, {"j._id": "j_id"}] });

полез проверять, у меня отработало

хех, видать доделали

полез проверять, у меня отработало

{ "_id" : 1, "obj" : [ { "_id" : 22, "field1" : "bla-bla", "field2" : [ { "_id" : 33, "nestedField" : "aaa" } ] }, { "_id" : 66, "field1" : "bla-bla", "field2" : [ { "_id" : 33, "nestedField" : "bb" } ] } ] } db.getCollection('nest').update( {"_id": 1}, {$set: {"obj.$[i].field2.$[j].nestedField": "new value"}}, {arrayFilters: [{"i._id": 22},{ "j._id": 33}] });

Я так пробовал уже. В итоге будет j недоступно, код ошибки 2, а текст badValue

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

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

Тот пример я написал от руки. Видимо в прошлые разы, когда тестировал пример с двумя параметрами в arrayFillter где-то допустил ошибку (хотя странно, перепроверял 2 раза). Но вариант который предложил @TonyTheFox тоже работает.

Но ради интереса нужно проверить:)

Да, проверил - работает тоже

У нас периодически (раньше было раз в неделю, сейчас почти каждый день) монго начинает съедать всю память, сервер тормозит и потом oom killer убивает монгу. Я пытался останавливать все запросы через db.killOp(), но это не помогает: даже когда все запросы убиты, память все равно не освобождается. БД небольшая - 14 ГБ. В логах вроде ничего криминального нет. Как можно диагностировать проблему?

У нас периодически (раньше было раз в неделю, сейчас почти каждый день) монго начинает съедать всю память, сервер тормозит и потом oom killer убивает монгу. Я пытался останавливать все запросы через db.killOp(), но это не помогает: даже когда все запросы убиты, память все равно не освобождается. БД небольшая - 14 ГБ. В логах вроде ничего криминального нет. Как можно диагностировать проблему?

а памяти сколько и кто еще крутится на том же серваке?

а памяти сколько и кто еще крутится на том же серваке?

Память 32 ГБ, на сервере еще есть nginx и приложение, которое с этой БД работает. Но остановка nginx и приложения не помогает.

Память 32 ГБ, на сервере еще есть nginx и приложение, которое с этой БД работает. Но остановка nginx и приложения не помогает.

А свап включен на сервере или виртуалке

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

А свап включен на сервере или виртуалке

Виртуализации нет, свап есть на 16 ГБ.

Ну и когда память начинает кончаться, свап тоже почти весь съедается.

Память 32 ГБ, на сервере еще есть nginx и приложение, которое с этой БД работает. Но остановка nginx и приложения не помогает.

мониторинг потребления памяти приложения и бд что говорит?

Если есть возможность, лучше мигрировать на сервер без свапа, хотябы саму монгу

Ну и когда память начинает кончаться, свап тоже почти весь съедается.

А вы используете что-то чтобы мониторить монгу?

А вы используете что-то чтобы мониторить монгу?

А чем ее можно мониторить?

Ну банально графаной и экспортерами

Ну банально графаной и экспортерами

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

Percona mongodb exporter

И node edporter

И node edporter

Если хотите анализировать насколько живой сам сервер

А подключение к прометеусу и графане сами разберёте

Там очень просто

Всем привет! Помогите новичку пожалуйста, устал курить мануалы))

{ }, { $set: { "parameters.$[elem].default" : "2023-01-01" } }, { arrayFilters: [ { "elem.id": { "periodStart" }, "elem.default": { "2023-01-01" } } ] } { $set: { "parameters.$[elem].default" : "2023-12-31" } }, { arrayFilters: [ { "elem.id": { "periodEnd" }, "elem.default": { "2022-12-31" } } ] } { $set: { "parameters.$[elem].default" : "2023" } }, { arrayFilters: [ { "elem.id": { "year" }, "elem.default": { "2022" } } ] } );

Это как то можно упростить, чтобы был один запрос на замену 2022** на 2023**

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

Это как то можно упростить, чтобы был один запрос на замену 2022** на 2023**

в обычном апдейте нельзя обращаться к текущим значениям полей для вычисления результата. Чтобы такое использовать нужно использова update with aggregation https://www.mongodb.com/docs/manual/tutorial/update-documents-with-aggregation-pipeline/ там уже можете накидать логику, но может быть нетривиально в случаем масивов

в обычном апдейте нельзя обращаться к текущим значениям полей для вычисления результата. Чтобы такое использовать нужно использова update with aggregation https://www.mongodb.com/docs/manual/tutorial/update-documents-with-aggregation-pipeline/ там уже можете накидать логику, но может быть нетривиально в случаем масивов

Извините, но я не понял))

Можете пример для тупых показать, пожалуйста? 😊

Извините, но я не понял))

а там не просто) сходу можно и не разобраться. Примеры по ссылке в examples. А дальше пишем обычную агрегацию чтобы получать доки в нужно виде, потом эту агргеацию пихаем в апдейт. Это лишь альтернатива, если задача разовая то добейте простыми апдейтами

здравствуйте, кто то работал с aws document db? у меня есть такой кластер, там крутится 5.0 версия. проблема в следующем - есть некие квери (обычный db.collection.find()), которые могут выполняться, скажем, более 30 секунд при некоторых обстоятельствах. я хочу такие квери вырубать по таймауту, чтобы они не висели просто так и не нагружали систему. стал гуглить, нагуглил параметр cursor.maxTimeMS(). Добавлял его к своим запросам (приложение на node js, клиент mongoose, но пробовал и нативный монговый, и шелл тоже) но квере как бы пох на этот мой параметр и она может крутиться там несколько минут. через robot 3t смотрел currentOps, находил там свои квери, и в параметрах запроса был указан maxTimeMS: 1000, а кверя уже крутится более 30 секунд, к примеру. как это должно работать и мб мне какой то другой параметр нужен?

здравствуйте, кто то работал с aws document db? у меня есть такой кластер, там крутится 5.0 версия. проблема в следующем - есть некие квери (обычный db.collection.find()), которые могут выполняться, скажем, более 30 секунд при некоторых обстоятельствах. я хочу такие квери вырубать по таймауту, чтобы они не висели просто так и не нагружали систему. стал гуглить, нагуглил параметр cursor.maxTimeMS(). Добавлял его к своим запросам (приложение на node js, клиент mongoose, но пробовал и нативный монговый, и шелл тоже) но квере как бы пох на этот мой параметр и она может крутиться там несколько минут. через robot 3t смотрел currentOps, находил там свои квери, и в параметрах запроса был указан maxTimeMS: 1000, а кверя уже крутится более 30 секунд, к примеру. как это должно работать и мб мне какой то другой параметр нужен?

вероятно aws document db не поддерживает эту опцию у курсора. documentDB это и не монга вовсе, это обёртка с монго-совместимым протоколом и фичами на уровне 3.x версии (если ничего не изменилось)

вероятно aws document db не поддерживает эту опцию у курсора. documentDB это и не монга вовсе, это обёртка с монго-совместимым протоколом и фичами на уровне 3.x версии (если ничего не изменилось)

в том то и дело что поддерживает и даже в доке конкретно про maxTimeMS что то написано https://docs.aws.amazon.com/documentdb/latest/developerguide/functional-differences.html#functional-differences.cursormaxTimeMS

cursor.maxTimeMS resets the counter for each getMore reques

cursor.maxTimeMS resets the counter for each getMore reques

что это означает?

что это означает?

счётчик таймаута сбрасывается каждый раз когда драйвер получает новую порцию документов через getMore это работает совсем не так как в монге, где maxTimeMS задаёт таймаут на всё время жизни курсора

счётчик таймаута сбрасывается каждый раз когда драйвер получает новую порцию документов через getMore это работает совсем не так как в монге, где maxTimeMS задаёт таймаут на всё время жизни курсора

я правильно понимаю что внутри одной такой квери, может быть выполнено несколько getMore реквестов?

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

Docker compose https://termbin.com/dqh6 mongo-init.js https://termbin.com/cyu5 Логи https://termbin.com/zv8u mongosh -u durachok -p cpp123321 --authenticationDatabase your_app_database Current Mongosh Log ID: 65d83701cdb3790f555906b6 Connecting to: mongodb://<credentials>@127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&authSource=your_app_database&appName=mongosh+2.1.5 MongoServerError: Authentication failed. Блин 3 день... что я делаю не так?

"error":"UserNotFound: Could not find user \"durachok\" for db \"your_app_database\"

"error":"UserNotFound: Could not find user \"durachok\" for db \"your_app_database\"

но я его создаю в инит скрипте

Docker compose https://termbin.com/dqh6 mongo-init.js https://termbin.com/cyu5 Логи https://termbin.com/zv8u mongosh -u durachok -p cpp123321 --authenticationDatabase your_app_database Current Mongosh Log ID: 65d83701cdb3790f555906b6 Connecting to: mongodb://<credentials>@127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&authSource=your_app_database&appName=mongosh+2.1.5 MongoServerError: Authentication failed. Блин 3 день... что я делаю не так?

из логов: "namespace":"admin.your_collection_2" что говорит что коллекции создаются в бд admin, которая указана в MONGO_INITDB_DATABASE. Чтобы создать в другой БД нужно использовать use your_app_database Соответсвенно надо ожидат ьчто и юзер был создан в админ бд, что подтверждает подкючение с authDb=admin Собсна в вашем случае надо либо перед выполнением команд на создание сущностей и юзеров указывать use somedb или просто указать нужную бд в MONGO_INITDB_DATABASE

из логов: "namespace":"admin.your_collection_2" что говорит что коллекции создаются в бд admin, которая указана в MONGO_INITDB_DATABASE. Чтобы создать в другой БД нужно использовать use your_app_database Соответсвенно надо ожидат ьчто и юзер был создан в админ бд, что подтверждает подкючение с authDb=admin Собсна в вашем случае надо либо перед выполнением команд на создание сущностей и юзеров указывать use somedb или просто указать нужную бд в MONGO_INITDB_DATABASE

в любом случае при MONGO_INITDB_DATABASE надо делать use?

в любом случае при MONGO_INITDB_DATABASE надо делать use?

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

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

https://termbin.com/k7z6 compose https://termbin.com/099c init https://termbin.com/m9e0 logs mongosh -u durachok -p 123321 --authenticationDatabase concert-suggester Current Mongosh Log ID: 65d8b7b942dcfc6cf8dd0dff Connecting to: mongodb://<credentials>@127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&authSource=concert-suggester&appName=mongosh+2.1.5 MongoServerError: Authentication failed.

https://termbin.com/k7z6 compose https://termbin.com/099c init https://termbin.com/m9e0 logs mongosh -u durachok -p 123321 --authenticationDatabase concert-suggester Current Mongosh Log ID: 65d8b7b942dcfc6cf8dd0dff Connecting to: mongodb://<credentials>@127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&authSource=concert-suggester&appName=mongosh+2.1.5 MongoServerError: Authentication failed.

читайте логи внимательно Error: Environment variable MONGO_ROOT_USERNAME is not set.

читайте логи внимательно Error: Environment variable MONGO_ROOT_USERNAME is not set.

внутри контейнера переменная будет MONGO_INITDB_ROOT_USERNAME

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

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

не понял юмора