Почему выборка с поиском по вложенному полю с обратной сортировкой тормозит?

Question

[Смотритель]

Приветствую.

Есть относительно небольшая база в 2.5млн документов. Структура документов не сильно важна, тем более она "динамическая". Но есть запрос, который выполняется регулярно и довольно часто - выборка "самого-самого" и по условию отсутствия вложенного поля:

db.getCollection('special').find({
    'checker.updated': { '$exists': false }
}).sort({'postedNum':-1}).limit(1)

Так вот дело в том, что этот запрос на базе выполняется около 40сек... Тогда как такой:

db.getCollection('special').find({
    'checker.updated': { '$exists': false }
}).sort({'postedNum':1}).limit(1)

выплевывает результат менее чем за одну.

Пробовал индексами химичить:
- раздельно на поля postedNum:-1 и checker.updated:1
- делал сдвоенные postedNum:-1 + checker.updated:1
- пробовал использовать индекс на весь checker

Результата ноль. Если сортировать по возрастанию - моментально, как только реверс на убывание - "куримбамбук". Даже появились мысли, не свалить ли на что-то реляционное скульное, но там останавливает скорость активной работы с таблицами размером более 20-25млн записей...

Update 1. Попробовал заменить фильтр с вложенного поля на простое (создал копию из 'checker.updated' => 'checkerUpdated') - тоже все стало "летать" и с прямой и с обратной сортировкой. Ничего не понимаю... Как вариант решения, конечно, отказаться полностью от "вложенной структуры", но блин, это перелопатить половину кода и накостылять кучу блоков, которые должны будут "сворачивать/разворачивать" рабочие структуры в одноуровневые списки полей

Update 2. А теперь вообще ничего не понимаю. Повырубал все процессы/ноды, которые выполняли в параллели один и тот же запрос с вот этой "обратной сортировкой" (условия оставил, сортировку убрал - что не есть хорошо, но как временный вариант подойдет), и тут же ушли дикие задержки на выполнение этого же самого запроса с 40с+ до 2с... Получается, что такие дикие задержки дает множество параллельных обращений к базе с одним и тем же запросом, но именно в сочетании "сортировка + фильтр по вложенному полю"... Что за фигня???

Answer 1

[Philipp]

Для начала неплохо было бы взглянуть на вывод explain.
Производительность приложения напрямую зависит от используемого индекса, но в данном случае вы используете $exists: false, что автоматически приводит к ситуации полного сканирования коллекции.
Индексирование такого поля не выход. Если вы хотите индексировать, то в индекс должно попадать значение.
Чтобы решить проблему, вам необходимо при вставке добавлять нечто вроде updated: false.
Если вы храните там дату, то используйте дополнительное поле updatedAt. Не следует смешивать разные типы данных в одном поле - монга может не построить индекс.
Для обратной сортировки вы можете создать дополнительный индекс с обратным порядком.
Подробнее о сортировках можно прочесть здесь https://docs.mongodb.com/manual/tutorial/sort-resu...
Вы можете построить совмещенный индес с прямым проходом по свойству и обратной сортировкой, только следует соблюдать порядок.

Comments

[Смотритель]

Philipp последовал вашему совету, но видимо не совсем верно. Использовал значение false для поля "без данных" (типа - не существует), а при заполнении в поле пишется строковое значение. Скорость увеличилась, индекс построился... Но тут словил одну непонятную ситуацию...
1. find({'field':false}) - быстро
2. find({'field':{$ne: false}}) - полный тухляк
3. find({'field:{$gt:''}}) - быстро

По полю делал индексы и прямой и обратный, ситуация не изменилась. Все три варианта используют индекс.

Просто непонятно, почему прямое сравнение === false выполняется быстро, а обратное по сути !== false умирает минуту (дальше просто терпение лопнуло)... Есть идеи?

[Philipp]

Артем, смотрите на вывод explain. Прокачанный навык телепатии говорит о том, что индекс не используется.
Не используется по причине того, что JS язык не типизированный, а значит необходимо производить сравнение, а значит приведение типов, и далее инвертировать результат.

Зачем делать find({'field':{$ne: false}}), когда можно делать просто find({'field': true})?

[Смотритель]

Philipp, сравнение "не false" - это очень редкая операция в принципе, постоянная операция сравнения как раз $gt и $lt - т.к. в поле некое подобие групповой сортировки что ли... Ну т.е. там пишется что-то типа "se032-dr-230-12/3442" - т.е. по сути поле заполняется по определенному строковому шаблону - который при сравнении как раз и получается что увеличивается, по нему и сортировку делают и отборы часто....

Answer 2

[Леонид]

потому что модные до недавнего времени nosql базы данных не предназначены для сложных и одновременно быстрых выборок.
Это не последняя ваша проблема - чем раньше перейдете на нормальную реляционную БД тем меньше проблем в будущем.

Comments

[Смотритель]

Да я чую, что именно это и нужно делать... Давно знакомый мускуль сразу правда, приходится отсекать, ибо помнится был опыт работы и таблицы с 1-2млн записей тормозили нещадно, а тут ожидается со временем наполнение под 100млн...
Хотя потянет ли постгре такие таблички или придется подумать хорошенько на тему партиций =(((

[Леонид]

если на компе достаточно памяти (а если еще и SSD ) и мускуль соответственно настроить то проблем не будет. Посгре не быстрее мускула - там просто более развитый sql
да и патрицирование в мускуле не проблема

[Смотритель]

Мигрировал коллекцию из монги на постгре и попробовал выполнить базовые запросы (нужные индексы построил) - как-то нерадужно. То, что на монге выдает данные за доли секунды, на постгре выполняется за почти 2 сек...
По сути ничего сложного нет и никаких связей тоже, все в одной табличке, прямым сравнением - просто таблица в 10млн записей...
Это как-то "обидно" что ли...

[Леонид]

Артем, елси надо ворочать большими данными то полагается использовать и сервера ентерпрайз уровня - mssql оракл и т.д.
Вообще в любых серверах БД есть куча настроек которые позволяют оптимизировать скорость. всякие там кеши и прочее
Если индекс не помещается в памятиь то толку от него немного

[Смотритель]

caballero, кто ж мне бесплатно даст МсСкл или Оракл =))) да и сомневаюсь я, что постгре по сравнению с ним не конкурент... да и таблицы в 50 лямов записей (в перспективе) как-то не тянут на мегаогромные