Естественно

ЕлементМатч возвращает документ, если хотя бы один элемент в массиве совпадет

Я сегодня тоже ипался с этим

Ты уверен что ты правильно данные кладешь?

Ты уверен что ты правильно данные кладешь?

да

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

?

Я бы так сделал

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

😕

он мне отдал все items из доки

https://docs.mongodb.com/manual/reference/operator/aggregation/filter/

Я только боюсь как бы группировка не сработала на документ целиком

Привет всем! Тут же есть специалисты по монге? Кто-нибудь знает как можно сделать аналог distinct по полю в коллекции за адекватное время. Индекс есть, но он не спасает. Знающие чуваки посоветовали использовать aggregation, но оно всё равно не работает особо быстро

Тут их нет, проверено))

Привет всем! Тут же есть специалисты по монге? Кто-нибудь знает как можно сделать аналог distinct по полю в коллекции за адекватное время. Индекс есть, но он не спасает. Знающие чуваки посоветовали использовать aggregation, но оно всё равно не работает особо быстро

Какие критерии адекватности времени? Сколько данных? Есть ли какие-то фильтры на выборке?

Какие критерии адекватности времени? Сколько данных? Есть ли какие-то фильтры на выборке?

Сейчас среднее время 4 секунды (с aggregation) или 8 секунд для distinct. Есть один фильтр secondfield: null, индекс сделан с таким же фильтром. Данных около 1m документов.

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

Сейчас среднее время 4 секунды (с aggregation) или 8 секунд для distinct. Есть один фильтр secondfield: null, индекс сделан с таким же фильтром. Данных около 1m документов.

После фильтрации сколько доков получается?

После фильтрации сколько доков получается?

Примерно все, с $ne: null не больше 10 тысяч

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

Да, но оба метода зачем-то делают full scan

Да, но оба метода зачем-то делают full scan

А если hint указать?

Уберите условие с нулом и постфактум его уберите из результата

А если hint указать?

Distinct использует индекс, но он сам по себе медленный

Уберите условие с нулом и постфактум его уберите из результата

Увы, это нельзя

Увы, это нельзя

Эм, как это нельзя? Что мешает?

Эм, как это нельзя? Что мешает?

Бизнес логика, которую нельзя мсключить

Не вижу проблемы вынести бизнес логику из базы в приложение

Не вижу проблемы вынести бизнес логику из базы в приложение

Тогда мне придется делать distinct по двум полям. Если коротко: каждый документ - один проданный продукт. Там где поле не null - это неоплаченный продукт. Мне нужно получать distinct по клиентам у которых есть оплаченные продукты

Мне проще завести отдельную коллекцию активных клиентов, чем переделывать эту логику

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

А зачем там вообще монга тогда?

А зачем там вообще монга тогда?

Типичный русский чат: на конкретно сформулированную проблему отвечают - вы не должны этого хотеть и вообще всё делаете неправильно

Типичный русский чат: на конкретно сформулированную проблему отвечают - вы не должны этого хотеть и вообще всё делаете неправильно

Я такого не говорил.

Я такого не говорил.

Короткий ответ: дизайн решения приняты не мной, но имеется весьма конкретное обоснование относительно существующей инфраструктуры в компании

Вам придется группировать скорее всего

К этом выводу всё таки пришёл. Надо будет каждое свойство разбить по коллекциям, прикрепить ссылки в виде ObjectID и работать так

Ибо я пытаюсь в нереляционке сделать реалиционку ( т.е. хернёй страдаю)

Короткий ответ: дизайн решения приняты не мной, но имеется весьма конкретное обоснование относительно существующей инфраструктуры в компании

Так может индекс перестроить? Может у вас неправильно сортируется таблица индекса и потому типа оптимизатор не выбирает его и считает что ему проще фулскан сделать?) Индекс и пример запроса в студию

Без них вряд-ли кто поможет

Так может индекс перестроить? Может у вас неправильно сортируется таблица индекса и потому типа оптимизатор не выбирает его и считает что ему проще фулскан сделать?) Индекс и пример запроса в студию

distinct работает плохо, про это разработчики монги сами говорят. А вот адекватной замены нет

distinct работает плохо, про это разработчики монги сами говорят. А вот адекватной замены нет

Distinct везде плохо работает

Вы дайте индексы

И пример запроса

Может кто чё увидит

db.getCollection('Col').explain("executionStats").aggregate( {$match: {'second': null}}, {$group: { "_id": "$first" }} )

Ну а индекс

Вы говорили у вас там null поле

Понял

Сори

Ну у вас есть индекс где просто second и поле id за ним?

А ещё, я сам 2 дня пользуюсь монгой, но у вас explain вызывается всегда, так прям в коде написано или для теста и только сейчас?

Более правильный запрос db.getCollection('Col').explain("executionStats").aggregate( [{$match: {'excludeField': null}}, {$group: { "_id": "$A" }}], {hint: { "A": 1, "B": 1 }} )

Да хорошо, индекс мне)

Index db.Col.createIndex({ "A": 1, "B": 1 }, {partialFilterExpression: {excludeField: null}});

"$cursor" : { "query" : { "excludeField" : null }, "fields" : { "A" : 1, "_id" : 0 }, "queryPlanner" : { "plannerVersion" : 1, "namespace" : "db.Col", "indexFilterSet" : false, "parsedQuery" : { "excludeField" : { "$eq" : null } }, "winningPlan" : { "stage" : "FETCH", "filter" : { "excludeField" : { "$eq" : null } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "A" : 1.0, "B" : 1.0 }, "indexName" : "A_1_B_1", "isMultiKey" : false, "multiKeyPaths" : { "A" : [], "B" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : true, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "A" : [ "[MinKey, MaxKey]" ], "B" : [ "[MinKey, MaxKey]" ] } } }, "rejectedPlans" : [] },

По-умолчанию без hint использует индекс db.Col.createIndex({excludeField: 1});

А у вас индексы дефрагментированны?

А у вас индексы дефрагментированны?

А это как-то поможет?

Чем индекс более фрагментирован тем медленнее он работает))

Я просто хз, какой командой запустить дефрагментацию и не делает ли моего ее сам

Но если у Вас миллион записей, а дефрагментации не было, то это в разы все замедлит

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

Но как бы тут вряд-ли как-то по другому

Все БД основы плюс-минус одинаковые

Попробуйте repairDatabase() запустить

Вот ещё compact есть

Попробуйте запустить и отпишитесь, если удачно

По-умолчанию без hint использует индекс db.Col.createIndex({excludeField: 1});

Лучше compact - это написано что явная дефрагментация

Я просто хз, какой командой запустить дефрагментацию и не делает ли моего ее сам

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

По-умолчанию без hint использует индекс db.Col.createIndex({excludeField: 1});

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

Более правильный запрос db.getCollection('Col').explain("executionStats").aggregate( [{$match: {'excludeField': null}}, {$group: { "_id": "$A" }}], {hint: { "A": 1, "B": 1 }} )

сделайте после матча $project где вы оставляете только ваши поля А и В, и после этого сделайте эксплейн без хинта

Более правильный запрос db.getCollection('Col').explain("executionStats").aggregate( [{$match: {'excludeField': null}}, {$group: { "_id": "$A" }}], {hint: { "A": 1, "B": 1 }} )

закиньте на гист весь результат эксплейна

Всем привет. Как наименее затратно сделать запрос в монго если такая структура: коллекция фирмы , у фирмы есть автосалоны своя коллекция, у автосалона есть подписчики , коллекция юзеры. Нужно выдать для фирмы первые 5 подписчиков. Голову ломаю как оптимизировать запрос. Проект на yii2

А что именно сейчас тормозит?

А что именно сейчас тормозит?

Запрос). Выбираются все автосалоны по ним getAll подписчики с лимитом 5

Ну т.е. там несколько запросов, по запросу на коллекцию? В mongodb есть такое https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/, но я сам не юзал.

Ну т.е. там несколько запросов, по запросу на коллекцию? В mongodb есть такое https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/, но я сам не юзал.

Спасибо почитаю

Ну, а в целом, не понятно, что там у вас. Что за запросы. Может быть, банально, индексы в память не влазят.

Всем привет. Как наименее затратно сделать запрос в монго если такая структура: коллекция фирмы , у фирмы есть автосалоны своя коллекция, у автосалона есть подписчики , коллекция юзеры. Нужно выдать для фирмы первые 5 подписчиков. Голову ломаю как оптимизировать запрос. Проект на yii2

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

Чем индекс более фрагментирован тем медленнее он работает))

Нет