Я имел ввиду вложенный массив

Как вы показали в общем

Тогда индекс примерно будет таким {access: 1, name: 1, bid: 1}

Какие-то странные проблемы на 100к записей

Какие-то странные проблемы на 100к записей

Если долбят постоянно коллекцию COLLSCAN'ами, то неудивительно

Тогда индекс примерно будет таким {access: 1, name: 1, bid: 1}

Если запрос без bid, то будет тоже он работать?

Если запрос без bid, то будет тоже он работать?

Да

Это index prefixing называется

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

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

Планировщик сам разрулит

Не факт

Нужно просто удостовериться потом при помощи explain

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

А это тоже влияет?

А это тоже влияет?

Зависит от версии монги, я думаю

Но это простой запрос, чтобы планировщик понял

эм

заморочился

).find({ "$or":[ {"owner_id" : 123, "bid":2321312}, {"admins.id" : 123, "bid":2321312} ] })

"winningPlan" : { "stage" : "SUBPLAN", "inputStage" : { "stage" : "FETCH", "inputStage" : { "stage" : "OR", "inputStages" : [ { "stage" : "IXSCAN", "keyPattern" : { "owner_id" : 1, "bid" : 1 }, "indexName" : "owner_id_1_bid_1", "isMultiKey" : false, "multiKeyPaths" : { "owner_id" : [], "bid" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "owner_id" : [ "[123.0, 123.0]" ], "bid" : [ "[2321312.0, 2321312.0]" ] } }, { "stage" : "IXSCAN", "keyPattern" : { "admins.id" : 1, "bid" : 1 }, "indexName" : "admins.id_1_bid_1", "isMultiKey" : false, "multiKeyPaths" : { "admins.id" : [], "bid" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "admins.id" : [ "[123.0, 123.0]" ], "bid" : [ "[2321312.0, 2321312.0]" ] } } ] } } },

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

).find({ "$or":[ {"owner_id" : 123, "bid":2321312}, {"admins.id" : 123, "bid":2321312} ] })

У меня другой запрос

Я не раз сталкивался, что обычный and по двум полям сваливался в colscan, если порядок полей не соответствовал индексу. По-моему этот случай даже в документации по pymongo описан при передаче dict-a, который не сортмрованный

Эксплейн https://pastebin.com/uvMDPsYb

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

Добавь сортировку теперь

"winningPlan" : { "stage" : "SUBPLAN", "inputStage" : { "stage" : "SORT", "sortPattern" : { "name" : 1.0 }, "inputStage" : { "stage" : "SORT_KEY_GENERATOR", "inputStage" : { "stage" : "FETCH", "inputStage" : { "stage" : "OR", "inputStages" : [ { "stage" : "IXSCAN", "keyPattern" : { "owner_id" : 1, "bid" : 1 }, "indexName" : "owner_id_1_bid_1", "isMultiKey" : false, "multiKeyPaths" : { "owner_id" : [], "bid" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "owner_id" : [ "[123.0, 123.0]" ], "bid" : [ "[2321312.0, 2321312.0]" ] } }, { "stage" : "IXSCAN", "keyPattern" : { "admins.id" : 1, "bid" : 1 }, "indexName" : "admins.id_1_bid_1", "isMultiKey" : false, "multiKeyPaths" : { "admins.id" : [], "bid" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "admins.id" : [ "[123.0, 123.0]" ], "bid" : [ "[2321312.0, 2321312.0]" ] } } ] } } } }

db.getCollection('tst').find({ "$or":[ {"owner_id" : 123, "bid":2321312}, {"admins.id" : 123, "bid":2321312} ] }).sort({name:1}).explain()

индексы те же что и в пастебине

Итого? :)

итого тебе нужно переписать азпрос

и построить два инедкса

Удаление индексов блокируют коллекцию?

добавление name к индксам, чуток меняет план на использование SORT_MERGE

если с ключом background:true то нет

момент

если с ключом background:true то нет

При удалении такого нет вроде.

упс, проглядел что вопрсо пр оудаление

Итого получаем сортировку в памяти

там нет никак пробелм

Индексы: Для овнера: { "owner_id" : 1, "bid" : 1, "name" : 1 } Для админов: { "admins.id" : 1, "bid" : 1, "name" : 1 } Фильтр для запросов: {"$or":[ {"owner_id" : 123, "bid":2321312}, {"admins.id" : 123, "bid":2321312} ]}

Итого получаем сортировку в памяти

это плохо?

это плохо?

Лишний расход cpu/ram

А если сделать подругому { name: "asd", access: [123123123, 123, 432], admins: [{...}, {...}], bid: 123321, owner_id: 123123123 } UPD.

Итого это лучший вариант?

Итого это лучший вариант?

Это лучший вариант по скорости выборки

Лишний расход cpu/ram

лишний расход на базе в 100к? смешно

лишний расход на базе в 100к? смешно

там есть другие базы с 50 млн. и 3 млн запросами в сутки

там есть другие базы с 50 млн. и 3 млн запросами в сутки

Вы хотите об этом поговорить?)))

Вы хотите об этом поговорить?)))

Об этом чуть позже. Next step. :)

Как попробуете отпишистесь о результатах

А если сделать подругому { name: "asd", access: [123123123, 123, 432], admins: [{...}, {...}], bid: 123321, owner_id: 123123123 } UPD.

Я вот так буду делать.

Так как удалить индексы не вырубить приложение?

просто дропай и все

удаление только замедлит запросы, котоыре их использовали

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

В идеале - по одной реплике переключать на новые индексы

Но 100к - это мало, даже не в бекграунде построение индекса займёт несколько единиц секунд

Хотя, в последних версиях вроде background-индексы не лочат слейвы

Ребят, прошел курсы по монге, получил на почту от них вот такое: Become a MongoDB teaching assistant. We are looking to hire teaching assistants for future courses. As a top performer, you may qualify for this paid position. To apply, fill out this form and we will contact you if there is an opportunity. Кто-нибудь участвовал в этом деле?

поучавствуешь — расскажи

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

можно

есть примерно такая коллекция: { _id: 1, name: "name1" prop: [ { key: "key1", value: 75}, { key: "key2", value: 78 }, { key: "key3", value: 70 } ] } приходит список новых свойств вида prop: [ { key: "key1", value: 90}, { key: "key4", value: 78 } ] то есть одно свойство изменилось и одно добавилось - как седлать обновление объекта в монге?

двумя запросами, в одном $elemMatch и $set с $, а второй просто $push

ок, просто в один запрос я тоже так и не смог придумать как это провернуть

а почему не хранить пропы как key1: 75 и т.д?

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

а почему не хранить пропы как key1: 75 и т.д?

потому что не надо их так хранить

если потом надо будет индексировать по названию поля — это будет невозможно

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

точн

т.е. резонный запрос, формата: найди мне key5 со значением больше 17 не будет возможен

ок, просто в один запрос я тоже так и не смог придумать как это провернуть

там в 3.6 навертели чего-то для массивов, можешь посмотреть

т.е. резонный запрос, формата: найди мне key5 со значением больше 17 не будет возможен

props.key5 { $gt: 17 }?

пропустил слово «по индексу»

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

пропустил слово «по индексу»

я че-то тоже забыл что речь про индексы

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

че-то такое ощущение что где-то такое есть

не могу вспомнить где

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

хорошие ODM, например mongoid в рубях, сам умеет делать дельту документа и сводить дельту к атомарной операции

в мысле что не целиком обновлять документ, а только изменившиеся поля