Счетчик MongoDB с запросами имеет низкую производительность

Подсчет количества записей в коллекции, соответствующих запросу, даже для индексированного поля занимает слишком много времени. Например, допустим, что есть коллекция, состоящая из 10000 записей, и есть индекс в поле createDate этой коллекции. Получение последних десяти записей из коллекции выполняется быстрее, чем подсчет количества записей, созданных в последний день. Для возврата результата запроса подсчета требуется более 5 секунд, иногда даже до 70 секунд. Есть ли у вас какие-либо идеи, как решить эту проблему, каков наилучший способ решить эту проблему?

Кстати, мы также используем morphia, и мы увидели, что получение подсчета с помощью morphia еще медленнее, поэтому для запросов на подсчет мы преобразуем запрос morphia в запрос драйвера Java. Кто-нибудь сталкивался с подобной ситуацией, почему морфий реагирует еще медленнее? Это происходит только для запросов на подсчет или в целом это медленно по сравнению с использованием только java-драйвера?

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

Заранее спасибо.


mongodb performance mongodb-query morphia mongo-java
person cubbuk    schedule 27.12.2012    source источник
comment
И запрос подсчета использует индекс? Какая версия MongoDB? Какая версия Java-драйвера? Можете ли вы опубликовать объяснение использования запроса для подсчета? Это должно заставить нас начать устранять неполадки.   -  person Sammaye    schedule 28.12.2012
comment
Версия MongoDB: 2.2, драйвер java: 2.7.3 (я должен проверить это дважды), morphia 0.99. У нас есть индекс поля, которое мы используем в запросе. Итак, в основном у меня есть простой запрос диапазона дат для индексированного поля, и мы вызываем функцию countAll для коллекции. Меня сейчас нет в офисе, позже я опубликую запрос с объяснением.   -  person cubbuk    schedule 28.12.2012
comment
Morphia 0.99 довольно старая. Рассматривали ли вы возможность обновления до форка, который включает некоторые исправления? Не уверен, что это помогает с производительностью, но это не должно повредить. И вывод .explain() вашего запроса должен помочь добраться до основной проблемы - этот запрос никогда не должен занимать так много времени.   -  person xeraa    schedule 28.12.2012
comment
следующая версия (2.4) значительно улучшит производительность подсчета. См. jira.mongodb.org/browse/SERVER-1752.   -  person Asya Kamsky    schedule 28.12.2012
comment
Не могли бы вы добавить запрос и .getIndexes()? И в идеале все в исходном вопросе - комментарии для этого не очень подходят :)   -  person xeraa    schedule 28.12.2012
comment
Запрос: {ua: {$gte: start, $lt: end}}, {ua:1}}. И у нас есть индекс по 14 различным полям, и ua — одно из этих полей. Я знаю, что такое количество индексов может создать проблемы, но наше приложение должно иметь столько запросов =)   -  person cubbuk    schedule 28.12.2012
comment
В целом это выглядит неплохо (n* все равны, scanAndOrder: false), только nYields довольно велико. Запрос приостанавливается 396 раз, чтобы позволить другим запросам выполняться, но если запрос занимает так много времени, и у вас есть другие запущенные, этого следует ожидать. Было бы интересно, если бы исправление в 2.4 помогло, но в противном случае я не могу обнаружить какой-либо серьезной проблемы. Ваши индексы помещаются в ОЗУ (db.stats())?   -  person xeraa    schedule 28.12.2012
comment
К сожалению, у нас почти 6 ГБ индекса, и кажется, что он не помещается в ОЗУ. Но интересно, что сервер, на котором хранится монго, всегда имеет 1-2 ГБ доступной оперативной памяти, как вы думаете, если мы переместим монго на сервер с большей памятью, будет ли значительное улучшение? Мне кажется основная проблема не в памяти.   -  person cubbuk    schedule 28.12.2012

Ответы (2)


arrow_upward
1
arrow_downward

Хотя это может быть не окончательный ответ, давайте начнем и продолжим:

  1. Ваши индексы всегда должны помещаться в оперативную память, иначе вы получите очень плохую производительность.

  2. Чтобы оценить, сколько оперативной памяти используется, вы можете использовать MMS 10gen или проверить с помощью различные инструменты. Описание и возможные причины низкого (резидентного) использования памяти см. на странице http://www.kchodorow.com/blog/2012/05/10/thursday-5-diagnosing-high-readahead/. Или вы просто еще не получили доступ к достаточному количеству данных, и в этом случае вы можете использовать Touch MongoDB (но я сомневаюсь, что у вас уже есть проблемы с производительностью).

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

person xeraa    schedule 28.12.2012
comment
Мы попробуем составные индексы, похоже, что большинство наших индексов не используются, потому что большинство наших запросов представляют собой композицию поля даты и другого поля, где у нас были индексы для отдельных полей. А за статью про малое использование памяти спасибо, тоже похоже на нашу ситуацию, учтем рекомендации из этой статьи. - person cubbuk; 31.12.2012
comment
Предложение в блоге сработало как по маслу =) Мы также увидели, что большинство наших индексов в конце концов не используются, пока мы не конвертируем их в составные индексы, прямо сейчас система работает намного эффективнее, спасибо за предложения и помощь =) - person cubbuk; 02.01.2013

arrow_upward
0
arrow_downward

Дождитесь исправления.

Как прокомментировала Ася Камская, производительность счета на 2.2 очень плохая. Единственный обходной путь, который мы нашли, — максимально избегать их.

(Есть и другие вещи, которые необъяснимо медленны с mongodb, такие как агрегированные запросы, большинство из которых связаны с проблемами JIRA и над которыми работают/планируются)

person ptyx    schedule 28.12.2012
comment
Похоже, что помимо проблемы с подсчетом монго, основная проблема заключается в нашей собственной архитектуре, мы будем переоценивать нашу систему, выбор правильных индексов кажется нам решающим. Кстати, мы с нетерпением ждем новой версии, чтобы увидеть, какова производительность для платформы подсчета и агрегации. - person cubbuk; 31.12.2012