$in затупляет монговский индекс на порядок-два

Explain может пролить свет

Не может.

а если $or?

https://www.arangodb.com

Нужно больше nosql баз. Их так мало запилили.

Скинь коллекцию, а то так просто не воспроизводится.

Интересное кино.

Покажи таки вывод explain, getIndexes и, если это возможно, приведи пример того, как у тебя выглядит типичный документ.

вывод explain

Собственно, интересует, нет ли там scanAndOrder: true

Разрешите раскопать RDBMS обратно, товарищ хипстор!

$or еще хуже.

Пробовали все на что хватило фантазии.

https://github.com/nodeca/nodeca.forum/blob/master/models/forum/Topic.js#L46-...

Вот. `st` - статус, по которому выборка делается.

Ссылка на документ выше. Вот гист с эксплейнами:

https://gist.github.com/Kirill89/bf51df7e0aebd04f494f

Там местами find вместо count, но на суть не влияет. Пробовали разные запросы и разные индексы из тех что под рукой.

Ты не умеешь в JS.

$or не правильно написан, оно ищет только st==2

А оно случайно не использует st первым полем индекса? Что будет если убрать hint?

В гисте далеко не все варианты. Поверь, если что-то можно было перепробовать, его перепробовали. Там еще есть запросы, когда надо считать статусы по диапазонам [дат/постов], но я привел самый простой пример, чтобы никого не грузить.

Проблема в отсутствии оптимизации на $in, которая ожидалась по аналогии с реляционками. Я помню, раньше $in вообще не работал. Потом дровосеки из 10gen отчитались, что осилили оптимизацию. Ну действительно, индекс использует. Но так что лучше бы совсем не работало.

Идея хорошая, но нет :)

https://gist.github.com/Kirill89/668f50c559f125d93d29

Работает только хардкор - посчитать по каждому статусу и сложить.

Вот зачем ? Когда есть PostgreSQL ломать голову с MongoDB ? Хипстеры :)

Почему-то у меня ощущение что ты не понял что я имел ввиду. Ну да ладно.

Можно не понимать как работают составные индексы и хотеть от БД какую-то «оптимизацию $in», но если руками два запроса работают - то зачем париться?

- потому что руками такое смотрится как через жопу
- потому что этот хак уже не прокатит для .skip(), когда надо пагинацию сделать.

Хинты там были потому что экспериментировали с индексами - перебирали разный порядок ключей. Убирание ни на что не влияет.

Скажи чем закончилось если проблема решится.

Счетчики привернули на соплях, как выше описывал. Еще в гуглогруппу напишем.

.skip() наверное пока отложим до выяснения. На списке постов проблема не очень острая и обходится кешированием (т.к. порядок постов не меняется, а инвалидация только при удалении).

На списке тем (сортируются по обновлению), с вменяемыми усилиями кеш не построить, но можно полностью похерить пагинацию. Сделав prev/next вида /?offset=mongo_id. Единственное, что меня останавливает от выпиливания пагинации в разделах - не придумал как это представить поисковикам. Чтобы потом не долбили динамические страницы но индексировали темы.

https://jira.mongodb.org/browse/SERVER-22574?filter=-2

Если кому надо - в жыре баг приняли и заредиректили на другой тикет. Но только для count. Если хотите чтобы skip + limit не сосал - репортите еще один баг.