оооо. плохо

это меньшая из проблем

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

вот это проблемы :)

и теперь это всё с тремя терабайтами, в продакшене, небось ещё и без существеного даунтама, да? :)

Здравствуй, монгочат. Я страдаю. У меня есть документ: { "_id" : 1.0, "role_permissions" : [ ["role1", ["perm1", "perm2"]], ["role2", ["perm3", "perm4"]] ] } Я хочу удалить, к примеру, вот это: ["role1", ["perm1", "perm2"]] Но я не знаю какие именно могут быть permissions в [1]. Поэтому я пишу что-то такое: db.originRuleSet.update( {'_id': 1}, { '$pull': { 'role_permissions.$.0': 'role1' } } ) А оно не работает :( При этом похожие примеры работают в случае если в nested arrays валяется object.

поменяйте схему на массив документов

role_permissions: [ {name: "role1", permissions: ["a", "b"]}, {name: "role2", permissions: ["a", "b"]} ]

поменяйте схему на массив документов

То есть это known bug? Просто мне интересно почему оно не хочет работать с голыми массивами и где прочитать про подобные ограничения.

с чего это баг

$ это positional оператор от $elemMatch

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

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

поменяйте схему

эта схема — очень неэффективная и будет доставлять вам _очень_ много боли

массивы и объекты в bson это одно и то-же

Уже попробовал, там всё равно трабла была в The positional operator did not find the match needed from the query. Прошёл в гугле по выхлопу, что-то понял

разница только в том, что в массиве ключи это индексы элементов

да, вам в любом случае нужен будет $elemMatch чтоб найти совпадение внутри массива

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

плюс можно будет нормально индекс сделать

эта схема — очень неэффективная и будет доставлять вам _очень_ много боли

А в чём неэффективность? То есть идея была в том, что изначально я хотел записать туда маппинг вида: {<roleName>: [perm1, perm2, ...]} На что мне сказали, что оно будет не айс и лучше воткнуть туда nested array.

плюс можно будет нормально индекс сделать

Кстати, а что за прикол вот этот? https://jira.mongodb.org/browse/SERVER-1068

А в чём неэффективность? То есть идея была в том, что изначально я хотел записать туда маппинг вида: {<roleName>: [perm1, perm2, ...]} На что мне сказали, что оно будет не айс и лучше воткнуть туда nested array.

вам как-то не очень корректно сказали

nested array это ужасный выбор в среднем

который примерно такой-же неэффективный как динамические имена ключей

role_permissions: [ {name: "role1", permissions: ["a", "b"]}, {name: "role2", permissions: ["a", "b"]} ]

^

Эх, короче буду переписывать пачку запросов уже готовых.

Кстати, а что за прикол вот этот? https://jira.mongodb.org/browse/SERVER-1068

¯\_(ツ)_/¯

¯\_(ツ)_/¯

Я просто рассчитывал на constraints из коробки, а они не пашут )

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

В общем, запрос правильный, по всей видимости, выглядит так: db.originRuleSet.updateOne( {'_id': 1, 'role_permissions': {'$elemMatch': {'role_name': 'role1'}}}, { '$pull': { 'role_permissions': { 'role_name': 'role1' } } } )

У меня есть ещё 1 вопрос не в кассу. Вот что я тут делаю этими апдейтами и прочим. Если я знаю заранее, что там будет очень мало апдейтов и записей, мб имеет смысл юзать локи и тупо реплейсить документ? Но с локами есть трабла: их завезди недавно, в используемой монге их нет. Как быть с блокировками, распраделёнными блокировками? Тащить etcd, zookeper и прочее не очень хочется. Мемлок будет работать только на 1 инстанс. Как вообще с этим живут монговоды?

зачем вам блокировка?

зачем вам блокировка?

Чтобы избежать race condition на обновлении. Просто кажется, что чем патчить данные такими запросами, проще обновить это руками и просто перезаписать объект

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

который ещё надо построить

если вам ради обновления надо тащить etcd или ещё какой-то zookeper вы где-то в своей архитектуре сильно не туда свернули

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

Окей, то есть вот все эти запросы такого вида с вложенностями — это нормально для мира монги? (я просто исследую варианты, потому что монгу я открыл ковырять вчера, потому что меняю работу, а у них монга)

да, вполне

Окей, тогда буду дальше ковырять, надеюсь привыкну. Спасибо

Чтобы избежать race condition на обновлении. Просто кажется, что чем патчить данные такими запросами, проще обновить это руками и просто перезаписать объект

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

и теперь это всё с тремя терабайтами, в продакшене, небось ещё и без существеного даунтама, да? :)

Пользователей нет. Можно вырубить на время

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

Уже переубедили, уже не планирую)

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

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

А, окей. Поскольку инстансов может быть поднято хоть 100, то один инстанс может лезть обновлять документ, второй — удалять что-то оттуда и т.д. Это породит race condition. Поэтому чтобы выпрямить запись нужен лок.

инстанс приложения?

инстанс приложения?

Да

Если мне память не изменяет, монга у них 3.6

@dd_bb привет. А ты не знаешь, почему текстовый индекс первым переносят в планировщике ?

@dd_bb привет. А ты не знаешь, почему текстовый индекс первым переносят в планировщике ?

Всмысле на первое место и выполняется он до прохода по всем другим полям, которые уже в fetch походу бегут

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

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

Жаль

можно попробовать хинтовать индексы

можно попробовать хинтовать индексы

Нельзя в одном запросе hint и $text

ну вот и ответ :)

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

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

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

вполне ответ: $text не пересекается с другими индексами

по этому hint и не доступен

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

текстовые индексы это очень сложно

Вот напрашивается переструкторирование планировщике задач, когда делается stage_andhash и stage_or на основе парсинга search терминов и только после этого уже передавать на fetch

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

можно начать с тикета в жире

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

Вот хорошая мысль да

можно начать с тикета в жире

Не, там их уже пачка. Все перечитал. Один из интересных - это несколько текстовых индексов на коллекцию

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

посмотреть на кого заассайнены

посмотреть на кого заассайнены

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

С 15 года

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

Хотя были push up в прошлом

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

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

сомневаюсь тогда что за три года стало меньше переписывать ;)

btree по чему?

по нормализованным словоформам?

по нормализованным словоформам?

Да

оно рубит текст по токенам, нормализует и делает ссылки из индекса на каждый токен?

Оно рубит текст на токену и делает ссылку на документ