Всем привет! Подскажите пожалуйста как удалить элемент image с id = 1 из такой структуры { name: 'companyName', options: [ { color: 'red', images: [ { imageId: '1', image: 'image1' }, { imageId: '2', image: 'image2' }, ], }, ], } Пробовал вот так db.companies.updateOne({'options.images.imageId': 1}, {$pull: {'options.images.$': 1}}) Появляется ошибка Cannot use the part (images) of (options.images.0) to traverse the element

[ { database: { _id: 'config', ... ... ... { database: { _id: 'crawler', primary: 'rs0', partitioned: true, version: { uuid: UUID("7c82efd0-3744-4480-9e0b-4b891ab2a01e"), timestamp: Timestamp({ t: 1691434708, i: 4 }), lastMod: 1 } }, collections: { 'crawler.pages33': { shardKey: { url: 1, hash: 1 }, unique: false, balancing: true, chunkMetadata: [ { shard: 'rs0', nChunks: 7136 } ], chunks: [ 'too many chunks to print, use verbose if you want to force print' ], tags: [] } } } ]

А у вас добавлены остальные шарады в конфигурацию? https://www.mongodb.com/docs/manual/reference/method/sh.addShard/

В $pull вам необходимо указать условие для удаление документа. В вашем случае это «options.images.imageId: 1»

shards [ { _id: 'rs0', host: 'rs0/mongodb-rs0-0.mongodb-rs0.infra.svc.k8s.us:27017,mongodb-rs0-1.mongodb-rs0.infra.svc.k8s.us:27017,mongodb-rs0-2.mongodb-rs0.infra.svc.k8s.us:27017', state: 1, topologyTime: Timestamp({ t: 1691434502, i: 3 }) } ] оператор сам добавил, но могу ошибаться)

Пробовал вот так db.companies.updateOne({'options.images.imageId': 1}, {$pull: {'options.images.$': 1}}) Появляется ошибка Cannot use the part (images) of (options.images.0) to traverse the element

Пробовал вот так db.companies.updateOne({'options.images.imageId': 1}, {$pull: {'options.images.$': 1}}) Появляется ошибка Cannot use the part (images) of (options.images.0) to traverse the element

И вот так пробовал одинаковая ошибка db.companies.updateOne({'options.images.imageId': 1}, {$pull: {'options.images.imageId': 1}})

В $pull не нужно использовать $. Просто еще раз повторите условие из update

Нашел вот такую историю https://github.com/Automattic/mongoose/issues/7147 Попробовал вот так { $pull: { options: { images: { imageId: 1 } } } } Ошибка исчезла, но сам объект не удалился из массива, хотя ответ апдейта { acknowledged: true, modifiedCount: 1, upsertedId: null, upsertedCount: 0, matchedCount: 1 }

ага, похоже не очень работает с dot notation. а вы уверены что у вас только один документы был с imageId: 1?

Нашел вот такую историю https://github.com/Automattic/mongoose/issues/7147 Попробовал вот так { $pull: { options: { images: { imageId: 1 } } } } Ошибка исчезла, но сам объект не удалился из массива, хотя ответ апдейта { acknowledged: true, modifiedCount: 1, upsertedId: null, upsertedCount: 0, matchedCount: 1 }

Не заметил что у вас options тоже массив db.getCollection("images").updateOne( { name: "companyA" }, { $pull: { "options.$[].images": { imageId: 1 } } } ) db.getCollection("images").find({ name: "companyA" }); → { "_id": { "$oid": "64e5fe27f13f9f421a05beaa" }, "name": "companyA", "options": [ { "color": "red", "images": [ { "imageId": 2, "image": "image2" } ] } ] },

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

Схему покажи

а еще чтото крутится на серваке? ощущение что память съедает не только монга но ее прибивают как самую прожорливую

If it’s not full copy of dbPath, including catalog file, then it’s the only option. But you can automate it with few lines of code

Коллеги, всем привет! Подскажите, а тут есть кто-нибудь, кто крутит монгу свыше 5.x версии в кубере?) Меня интересует потребление ресурсов с переходом на mongosh в exec проверках.

Битнамовским чартиком ) и сразу воткнулся вот в эту фигню https://github.com/bitnami/charts/issues/10316

Только тестирую пока что) Оператором поднимали?

А у вас перкона оператор ?

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

Подвернулась базёнка весом в 5G, в которую напхали 3.5к+ коллекций. Это барахло в линухе ресторится только на сервере с 40G рамы и на любые параметры ему плевать. На серверах похилее рестор фэйлится, СУБД отстреливается. Воспроизводится абсолютно на всех версиях. error running create command: connection(localhost:27017[-5]) socket was unexpectedly closed: EOF В винде ресторится успешно, но тоже выжирает прилично рамы - 10G почти. Это фэйспалм какой-то 🤦.

40G для монги вроде не супер много? мы вроде по 256 bare metal под монгу брали, но могу уточнить у программистов

Подвернулась базёнка весом в 5G, в которую напхали 3.5к+ коллекций. Это барахло в линухе ресторится только на сервере с 40G рамы и на любые параметры ему плевать. На серверах похилее рестор фэйлится, СУБД отстреливается. Воспроизводится абсолютно на всех версиях. error running create command: connection(localhost:27017[-5]) socket was unexpectedly closed: EOF В винде ресторится успешно, но тоже выжирает прилично рамы - 10G почти. Это фэйспалм какой-то 🤦.

да, не увидел 5г цифру изначально, извините, а индексы сколько весят?

Та 700 мб. Кастомных нет вообще, только _id дефолтные.

Подвернулась базёнка весом в 5G, в которую напхали 3.5к+ коллекций. Это барахло в линухе ресторится только на сервере с 40G рамы и на любые параметры ему плевать. На серверах похилее рестор фэйлится, СУБД отстреливается. Воспроизводится абсолютно на всех версиях. error running create command: connection(localhost:27017[-5]) socket was unexpectedly closed: EOF В винде ресторится успешно, но тоже выжирает прилично рамы - 10G почти. Это фэйспалм какой-то 🤦.

Да это хозяйство надо приводить к вменяемому виду. Убивать всё, что не требуется, чего там много я уверен, а всё остальное мёрджить в одну коллекцию и пусть переписывают код на людской. Там по сути с виду всё одинаковое, разбитое по периодам. 50 лямов доков на 3.5к коллекций. Скриптовать что-то ради одного такого гуманоида я не буду, но сам факт такого поведения при ресторе меня удивил и заставил поприседать с разными версиями, параметрами, настройками окружения и ОСями.

так а не проще сделать экспорт в json , сделать concat из всех фйлов в один, и потом нормально импортнуть?

Зачем? Чтобы слить кучу кусков в один, ничего никуда не надо выгружать, всё делается внутри СУБД.

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

Собственно, развернул кластер з 3 шардами, настроил шардирование для коллекции и запустил импорт 100гб в коллекцию. в sh.status() вижу следующее: { 'Currently enabled': 'yes', 'Currently running': 'no', 'Failed balancer rounds in last 5 attempts': 0, 'Migration Results for the last 24 hours': { '14': "Failed with error 'aborted', from rs1 to rs2", '25': "Failed with error 'aborted', from rs0 to rs2", '31': "Failed with error 'aborted', from rs2 to rs1", '32': "Failed with error 'aborted', from rs1 to rs0", '151': 'Success', '223': "Failed with error 'aborted', from rs2 to rs0" } } как полечить или больше информации увидеть?)

Собственно, развернул кластер з 3 шардами, настроил шардирование для коллекции и запустил импорт 100гб в коллекцию. в sh.status() вижу следующее: { 'Currently enabled': 'yes', 'Currently running': 'no', 'Failed balancer rounds in last 5 attempts': 0, 'Migration Results for the last 24 hours': { '14': "Failed with error 'aborted', from rs1 to rs2", '25': "Failed with error 'aborted', from rs0 to rs2", '31': "Failed with error 'aborted', from rs2 to rs1", '32': "Failed with error 'aborted', from rs1 to rs0", '151': 'Success', '223': "Failed with error 'aborted', from rs2 to rs0" } } как полечить или больше информации увидеть?)

Привет всем) В проекте использую replica set и все методы API обернуты в транзакции. При повышении нагрузки в проекте (примерно до 1000 операций в секунду), транзакции начинают конфликтовать друг с другом и отдельные транзакции валятся. При этом получаю ошибку: Plan executor error during findAndModify :: caused by :: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction. Подскажите пожалуйста, в каком направлении копать?

Привет всем) В проекте использую replica set и все методы API обернуты в транзакции. При повышении нагрузки в проекте (примерно до 1000 операций в секунду), транзакции начинают конфликтовать друг с другом и отдельные транзакции валятся. При этом получаю ошибку: Plan executor error during findAndModify :: caused by :: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction. Подскажите пожалуйста, в каком направлении копать?

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

Это нормальное поведение при конкуренции за ресурсы. логику разрешения конфликтов необходимо реализовать на вашей стороне

domain.com/v1/items?page=1&start=2023-08-25 Есть endpoint который выдает все товары. Как правильно выдавать только товары от указанной даты до момента запроса? Такой формат времени ок или это не канон?

На винде всё нормально работало, на линуксе вот

Ваерволл

what is wrong here?

Usefindandnodify ni false qb qoygansiz

true qilib qoyaymi?