Настройка индекса MongoDB 2.6, запрос с использованием $или, $in, с ограничением и сортировкой

Я не уверен, что это ошибка в MongoDB 2.6, но вы можете взглянуть на в этой статье создание индекса.

порядок полей в индексе должен быть:

1. First, fields on which you will query for exact values.
2. Second, fields on which you will sort.
3. Finally, fields on which you will query for a range of values.

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

$col->ensureIndex(array('owner' => 1, 'ca' => -1));
$col->ensureIndex(array('ca' => -1, 'owner' => 1, 'perm.type' => 1));
$col->ensureIndex(array('perm.list' => 1, 'ca' => -1, 'owner' => 1));

Edit:

из вашего объяснения, если вы тестируете на небольших наборах данных, полная коллекция быстро, потому что MongoDB не нужно проходить через много документы. Вы должны попробовать сделать тест с e.g 10000 документов, чтобы увидеть реальную разницу. Значения для ваших полей в индексах должны быть достаточно разными, чтобы обеспечить избирательность индексов для ваших запросов (например, не все документы от одного владельца).

TL; DR: я считаю, что вы используете неправильный алгоритм/структура данных для инструмента, или наоборот. Я бы предложил использовать подход fan-out как обсуждается в этом так вопрос или мой блог. Извините за бесстыдную рекламу моих предыдущих сообщений, но нет смысла повторять эту информацию здесь.

философия MongoDB, вопреки типичной SQL-философии, должна быть скорее писать-тяжелый. Ты по сути, пытается реализовать алгоритм ранжирования в запросе MongoDB, но философия запросов MongoDB - "запрос на примере". Это не подходит.

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

все, что вы делаете здесь очень трудно контролировать. Вы не только хотите, чтобы MongoDB использовал индекс пересечение (новое в 2.6, работает только с двумя индексами), но вы также объединяете его с $in запросы и составные индексы. Это много, чтобы спросить, и если количество друзей в $in растет слишком много, вам все равно не повезло. То же самое верно, если новость передается слишком многим людям, в худшем случае документ растет за 16 МБ. Растущие документы дороги, сложные запросы дороги, большие документы дороги тоже.

Я предлагаю вам использовать подход fan-out для новостных лент, где вы можете реализовать очень сложный алгоритм ранжирования в коде, а не в MongoDB.

Я не говорю, что невозможно оптимизировать ваш запрос, но так как настолько ginourmous и есть так много эффектов, взаимодействующих здесь (типичные размеры массива, типичный коэффициент соответствия, селективность индексов и т. д.), будет очень трудно найти хорошее решение этой проблемы, даже для тех, кто имеет полный доступ к данным (т. е. вы).

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