Критерий Проверки это подключение в бд через какой нибудь компас

environment: - MONGO_INITDB_ROOT_USERNAME=rootuser - MONGO_INITDB_ROOT_PASSWORD=rootpass

Добрейшего времени суток! Подскажите, плиз, если сможете. Есть коллекция с полем order, у которого, конечно же, есть индекс уникальности. И есть потребность менять этот порядок сразу у нескольких записей, сохраняя при этом неповторяемость величины order. Пробовал через операцию bulk_write - но получаю по шапке ошибкой "duplicate key error collection" - Индекс бдит! Очень не хочется городить огород с удалением-вставкой и прочей синтетикой, неужели нельзя как-то сразу поменять несколько записей не провоцируя проверку индекса?

А зачем это поле нужно? какой бизнес смысл

Например, приоритет в очереди. Очередность хостов внешних сервисов, etc.

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

Нет, не выбыл. Это не очередь, а очерёдность. Никто ниоткуда не выбывает. Просто какой-то документ надо "поднять повыше", смещая, разумеется, всех кто после него.

Но если есть нативный индекс уникальности, если можно всё и сразу (или нельзя) - то why not?

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

если документов немного, то заводите документ с массивом в котором держите идентификаторы документов, позиция в массиве - это ваш порядок

Тогда индекс уникальный не надо. А человеку это важно

А как вы определяете порядок?

Я не про это, а как вы решаете у какого документа 1, а у какого 5?

Я если честно не совсем понимаю, что вы хотите средствами монги сделать. Проверить уникальность? Индекс проверяет. И не даёт появлению дубликатов.

Индекс уникальности служит для того, что бы не было дубликатов. А вы как я понимаю хотите делать дубликаты.

Делаю aggregate.$lookup как мне сделать выборку по as, что она пустая ?

вопрос на общее понимание, если есть 2 индекса: index 1. Compound из 2 полей: a и b index 2. и индекс по 3 полю: с агрегация match при поиске по a и b match по полю c Используется только индекс 1? Вопрос в том, что искать по полю c на долгое время - не было нужды, тут вдруг захотели искать по 3 полям. Чтоб не перестраивать индекс 1 (да и по нему чаще будет поиск чем по 3 полям), добавили по полю c. В надежде что монга, найдет документы по a и b и в них с использованием индекса по c - быстро вернет. Но судя по explain - индекс по c - не используется

Привет! Прошу извинить Сообщество за вопрос от неофита, но... как можно создать пользователя? Делаю db.createUser( { user: “User”, pwd: “PassworD”, roles: [ { role: “readWrite”, db: “User” } } ) Но он не создаётся (судя по show users), хотя ошибки нет... пытаюсь понять где не прав я...

скорее всего планировщик не видит смысла в использовании индекса 2, т.к. его селективность ниже уже использованного индекса 1, а делать кроссмерж выборку по двум индексам еще дороже по операциям и затратам на диски.

А как себя будет вести планировщик, при наличии индекса по 3 полям и по 2 полям. То есть индекс 1 оставляем, и строим идекс по полям a b c. Если нужно будет искать по тройке значений. Будет ли в одних случаях использваоться индекс 1 а в других индекс 2

и если указаны два, то тот что горячее (в кеше) и опять же селективнее, а то вы можете же сделать индексы a-b и b-a-c и какой из них будет выбран зависит от того что быстрее сузит область поиска

Я соблюдаю и там и там один порядок в индексе a - b - c. И ищу через агрегаци, только а,b; a,b,c

Тогда вам за глаза одного индекса тройного

Тогда вам за глаза одного индекса тройного

У меня почему то при запросе по полям которые есть в индексе используется индекс с меньшим количеством полей. Я так и не разобрался почему.

Добрый день, подскажите, что это за странный Slow quert {"t":{"$date":"2022-09-14T04:36:21.976+00:00"},"s":"I", "c":"COMMAND", "id":51803, "ctx":"conn583","msg":"Slow query","attr":{"type":"command","ns":"catalog.$cmd","command":{"update":"addressCatalog","ordered":true,"lsid":{"id":{"$uuid":"84d565df-84f8-400e-adf9-fdbfe3c52457"}},"$clusterTime":{"clusterTime":{"$timestamp":{"t":1663130159,"i":1}},"signature":{"hash":{"$binary":{"base64":"jZFEXMui1QHBAc8MqXF1ProF8Ik=","subType":"0"}},"keyId":7138406697319530499}},"$db":"catalog"},"numYields":580,"reslen":245,"locks":{"ParallelBatchWriterMode":{"acquireCount":{"r":581}},"ReplicationStateTransition":{"acquireCount":{"w":582}},"Global":{"acquireCount":{"r":1,"w":581}},"Database":{"acquireCount":{"w":581}},"Collection":{"acquireCount":{"w":581}},"Mutex":{"acquireCount":{"r":1}}},"flowControl":{"acquireCount":581,"timeAcquiringMicros":1134},"storage":{},"protocol":"op_msg","durationMillis":7333}}

Добрый день, есть запрос db.personCatalog.find({simpleFirstName:"daniel", simpleLastName:"garvey", isDisabled:null, nationwideOrder:{$gt:0, $lte:20}}).limit(20) но он почему то игнорирует индекс { "v" : 2, "key" : { "simpleFirstName" : 1, "simpleLastName" : 1, "nationwideOrder" : 1, "isDisabled" : 1 }, "name" : "simpleFirstName_1_simpleLastName_1_nationwideOrder_1_isDisabled_1", "background" : true } использует индекс { "v" : 2, "key" : { "simpleFirstName" : 1, "simpleLastName" : 1, "state" : 1, "stateOrder" : 1 }, "name" : "simpleFirstName_1_simpleLastName_1_state_1_stateOrder_1", "background" : true },

Добрый день, есть запрос db.personCatalog.find({simpleFirstName:"daniel", simpleLastName:"garvey", isDisabled:null, nationwideOrder:{$gt:0, $lte:20}}).limit(20) но он почему то игнорирует индекс { "v" : 2, "key" : { "simpleFirstName" : 1, "simpleLastName" : 1, "nationwideOrder" : 1, "isDisabled" : 1 }, "name" : "simpleFirstName_1_simpleLastName_1_nationwideOrder_1_isDisabled_1", "background" : true } использует индекс { "v" : 2, "key" : { "simpleFirstName" : 1, "simpleLastName" : 1, "state" : 1, "stateOrder" : 1 }, "name" : "simpleFirstName_1_simpleLastName_1_state_1_stateOrder_1", "background" : true },

поля по которым делается выборка диапазоном должны идти в конце чтобы опять же селективность дала пользу а не доп выборки по IO. В вашем случае надо сделать индекс "simpleFirstName" : 1, "simpleLastName" : 1, "isDisabled" : 1 "nationwideOrder" : 1,

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

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

Тогда не совсем понял про селективность. IsDisabled самая низкая. Есть только у 1% записей

поэтому стоит перед полем по которому идет запрос диапазоном

{ 'from': 'message_v2', 'as': 'message', 'let': { 'chat_room_id': '$chat_room._id' }, 'pipeline': [{ '$match': { '$expr': { '$eq': ['$$chat_room_id', '$chat_room'] } } }, { '$sort': { '_id': 1 } }] } гайз, как работает сорт в данном случае? я правильно понял что он отсортирует мне НАЙДЕННЫЕ (прилукапенные) значения? если да, то почему этот запрос выполняется в разы дольше чем этот? { 'from': 'message_v2', 'as': 'message', 'let': { 'chat_room_id': '$chat_room._id' }, 'pipeline': [{ '$match': { '$expr': { '$eq': ['$$chat_room_id', '$chat_room'] } } }] } Индекс на chat_room стоит

{ 'from': 'message_v2', 'as': 'message', 'let': { 'chat_room_id': '$chat_room._id' }, 'pipeline': [{ '$match': { '$expr': { '$eq': ['$$chat_room_id', '$chat_room'] } } }, { '$sort': { '_id': 1 } }] } гайз, как работает сорт в данном случае? я правильно понял что он отсортирует мне НАЙДЕННЫЕ (прилукапенные) значения? если да, то почему этот запрос выполняется в разы дольше чем этот? { 'from': 'message_v2', 'as': 'message', 'let': { 'chat_room_id': '$chat_room._id' }, 'pipeline': [{ '$match': { '$expr': { '$eq': ['$$chat_room_id', '$chat_room'] } } }] } Индекс на chat_room стоит

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

Ерунда, 5-6

и разница именно в разы?

и разница именно в разы?