У нас есть большие многогигабайтные наборы данных, по которым мы выполняем очень сложные запросы, например
{
$or: [ { id: 30000001, ... }, { id: 30000005, ... }, ..., { id: 30001005, ... } ]
}
Кажется, что ЦП на самом деле является узким местом на данный момент, поэтому было бы полезно иметь возможность запускать несколько экземпляров mongod на одном и том же наборе файлов базы данных.
Мы рассмотрели возможность использования наборов реплик с этой целью, но не хотели бы требовать дополнительного дискового пространства просто по причинам ЦП.
Нет, это невозможно, в настоящее время вы не можете запускать несколько экземпляров с использованием одних и тех же файлов - ключевой функциональности, которая вам может понадобиться (управление тем, какой экземпляр имеет возможность записывать в файл), не существует. Я также не думаю, что это входит в список запросов функций (я не смог его найти), и, учитывая количество потенциальных проблем, которые я могу придумать, чтобы позволить это сделать, это могло бы показаться долгим шансом с точки зрения просьба, но вы можете запросить это.
В $or Пример запроса, который вы перечисляете (и вы предлагаете иметь более сложные), будет запускать несколько запросов параллельно, и, судя по всему, вы получите по существу вложенные логические $ors путем перечисления нескольких _id в каждом пункте. С многократным сканированием для каждого пункта в $or, даже с закрытым запросом индекса, который по-прежнему будет представлять собой большое количество сканирований индекса, когда этот массив большой.
Если вы не используете покрытые индексы (ищите indexOnly как true в ваших объяснениях), тогда это будет означать также много сканирования документов, и если весь ваш набор данных не умещается в памяти, это будет означать много ошибок страницы.
Поскольку вы уже заявляете, что это «единственный способ» сделать это в вашей системе (я думаю, что обзор схемы также был бы хорошей идеей), то в настоящее время, если у вас возникают проблемы с процессором на одном хосте, тогда репликация или Шардинг - это два варианта горизонтального масштабирования. Я также хотел бы убедиться, что процессор находится на земле пользователя, а не в системе (самый простой способ сделать это - установить MMS с участием Мунин-узел и отслеживать пользователя (обычно mongod, если это выделенная система) по сравнению с процессором системы с течением времени.
Однако прежде чем вы это сделаете, убедитесь, что вы работаете на 2.2 - одним из основных улучшений в 2.2 стала переключатель к TCMalloc - Я не могу быть уверен, потому что проблемы с malloc могут быть трудно диагностировать / определить в лучшем случае, но если вы используете 2.0, TCMalloc может вам здесь помочь.