Мне показалось грубым, его ответ "ссылку пожалуйста". Я понимаю что в ответ ссылка на гугл это "токсично", но до такой степени быть ленивым, это тоже не есть гуд

Лол, ты точно ему адресовал?

Всем привет, подскажите почему монго для одного и того же запроса с виду рандомно выбирает разные индексы? Есть один длинее и один короче, тот что длинее идеально подходит под запрос, а оно всёравно бывает выбирает тот что короче. Сам запрос, фильтр: { sport: 'Football', leagueGroup: 1, isFinished: true, 'season.startYear': { '$in': [ 2023 ] } } Сортировка: {startTime: -1} Два индекса: 1)sport_1_leagueGroup_1_isFinished_1_season.startYear_-1_startTime_-1 2)sport_1_leagueGroup_1_isFinished_1_startTime_-1 Содержимое explain: https://pastebin.com/wkE246tT

Всем привет, подскажите почему монго для одного и того же запроса с виду рандомно выбирает разные индексы? Есть один длинее и один короче, тот что длинее идеально подходит под запрос, а оно всёравно бывает выбирает тот что короче. Сам запрос, фильтр: { sport: 'Football', leagueGroup: 1, isFinished: true, 'season.startYear': { '$in': [ 2023 ] } } Сортировка: {startTime: -1} Два индекса: 1)sport_1_leagueGroup_1_isFinished_1_season.startYear_-1_startTime_-1 2)sport_1_leagueGroup_1_isFinished_1_startTime_-1 Содержимое explain: https://pastebin.com/wkE246tT

а проблема в чем?

При нужном индексе запрос идет 3м а при другом 8м, в этом проблема

В 2,5 раза где-то

ну а на что это влияет? у вас sla на сервисе 5м и 3 ок а 8 не ок?

Ну так всёравно чем быстрее тем лучше, это не совсем для внетреннего пользования, клиенту проще подождать 3м а не 8, и это же не на 10% оптимизация, а на 250%, считаю вполне оправданным, тем более всё что нужно это заставить работать правильный индекс

Всем привет, подскажите почему монго для одного и того же запроса с виду рандомно выбирает разные индексы? Есть один длинее и один короче, тот что длинее идеально подходит под запрос, а оно всёравно бывает выбирает тот что короче. Сам запрос, фильтр: { sport: 'Football', leagueGroup: 1, isFinished: true, 'season.startYear': { '$in': [ 2023 ] } } Сортировка: {startTime: -1} Два индекса: 1)sport_1_leagueGroup_1_isFinished_1_season.startYear_-1_startTime_-1 2)sport_1_leagueGroup_1_isFinished_1_startTime_-1 Содержимое explain: https://pastebin.com/wkE246tT

а season.startYear это вложенный объект или оно еще и в массиве?

Вот так это выглядит

значит планировщик прост опосчитал что проще профильтровать уже упорядоченный список, т.к "sport": 1, leagueGroup": 1, isFinished": 1, фактически все указывает на одну уникальную группу в индексе sport_1_leagueGroup_1_isFinished_1_startTime_-1 чем заниматься сортировкой отдельных кусков, получаемых в другом индексе

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

https://www.mongodb.com/docs/manual/reference/method/cursor.hint/

Модераторам не нужно знать данную информацию.

Привет, подскажите пж, как сюда регулярку пихнуть, гуглил - не помогло решение, с добавлением $regex {}. регулярка сделана через new RegExp. при обычном отборе find отрабатывает четко, а в агрегации - выводит только полные совпадения, а надо как в find, чтоб полноценно регулярка отрабатывала, как регулярка, а не просто строка) если что подскажете дельное - буду благодарен, если еще и обьясните - буду счастлив !

Привет, подскажите пж, как сюда регулярку пихнуть, гуглил - не помогло решение, с добавлением $regex {}. регулярка сделана через new RegExp. при обычном отборе find отрабатывает четко, а в агрегации - выводит только полные совпадения, а надо как в find, чтоб полноценно регулярка отрабатывала, как регулярка, а не просто строка) если что подскажете дельное - буду благодарен, если еще и обьясните - буду счастлив !

хз как в монгусе, в mongosh/compass это делается так {"data.field": {$regex: "regoolyarka toot"}}

именно так у него и сработало в find, в агрегации это не работает

Не надо regexp пихать в запрос, кидай строку, в монге своя обработка регулярок

Не надо regexp пихать в запрос, кидай строку, в монге своя обработка регулярок

ребята, а из-за чего может быть такая ошибка?

Наверное ты подключил аунтификацию и ssl но в линк не того не другого не дал

Привет, подскажите пж, как сюда регулярку пихнуть, гуглил - не помогло решение, с добавлением $regex {}. регулярка сделана через new RegExp. при обычном отборе find отрабатывает четко, а в агрегации - выводит только полные совпадения, а надо как в find, чтоб полноценно регулярка отрабатывала, как регулярка, а не просто строка) если что подскажете дельное - буду благодарен, если еще и обьясните - буду счастлив !

{ $match : { 'a.key' : { $regex : '^startsWithStr' }}} { $match : { title: { $regex: :#{#filter.q}, $options: 'i' }}

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

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

compass

я про веб именно)

а зачем такие извращения?

Привет ! Подскажите, почему данных запрос не использует индекс: {"$and":[{"<index_field_name>":{"$not":{"$regex":"<some_regex_here>"}}}]}

Documents Returned: 5935 Index Keys Examined: 0 Documents Examined: 123911 Actual Query Execution Time (ms): 32801 Sorted in Memory: no No index available for this query.

А с $in индекс работать будет ?

ребят, логи с 500 ошибками можно писать в отдельную коллекцию монго?

Помогите, при findbyid получаю какой то объект query. Что это?

как и в доке, все сходится. А что ожидается?

Ну объект который с искомым _id

await или exec()

ребят, не знаете как называется библиотека в node js, которая контролирует кол-во запросов с клиента?

{ $match : { 'a.key' : { $regex : '^startsWithStr' }}} { $match : { title: { $regex: :#{#filter.q}, $options: 'i' }}

аналогично, возвращает в мэтч только все документы с где значение реквизита равно ПЕРВОМУ совпавшему значению с регуляркой, а надо по ВСЕМ совпадениям чтоб вернуло из блока мэтча)

По картинкам такое себе удовольствие ванговать, проверь свой регекс на regex101