Как MonogoDB складывается для очень больших наборов данных, где только некоторые данные являются изменчивыми - PullRequest
8 голосов
/ 04 февраля 2011

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

Основным видом будет страница профиля в стиле Facebook для каждого контакта из самых последних (около 20) разговоров, которые каждый из них имел с полученной нами электронной почтой.

Для нас важно иметь возможность быстро и быстро получить страницу профиля и последние 20 элементов.Мы также можем часто вставлять последние электронные письма в этот канал.Для этого хранение документов и недорогая атомарная запись MongoDB кажутся довольно привлекательными.

Однако у нас также будет БОЛЬШОЙ объем старых разговоров по электронной почте, к которым не будет частого доступа (так как они не будутпоявляются в последних 20 элементах, люди увидят их, только если будут искать их, что будет относительно редко).Кроме того, размер этих данных будет расти быстрее, чем хранилище контактов.

Из того, что я прочитал, MongoDB, похоже, более или менее требует, чтобы весь набор данных оставался в оперативной памяти, и единственноеспособ обойти это заключается в использовании виртуальной памяти, которая может нести значительные накладные расходы.В частности, если Mongo не сможет различить изменчивые данные (профили / каналы) и энергонезависимые данные (старые электронные письма), это может оказаться довольно неприятным (и, поскольку кажется, что оно выделяет виртуальную память для ОС,Я не понимаю, как это было бы возможно для Монго).

Казалось бы, единственный выбор - либо (а) купить достаточно ОЗУ для хранения всего, что хорошо для изменчивых данных, но вряд ли экономически выгоден для захвата ТБ электронных писем, или (б) использовать виртуальную память и видеть, что чтение / запись на наших изменчивых данных замедляется до скорости сканирования.

Это правильно, или я что-то упустил?Будет ли MongoDB хорошо подходит для этой конкретной проблемы?Если это так, как будет выглядеть конфигурация?

Ответы [ 4 ]

3 голосов
/ 04 февраля 2011

MongoDB не"требует, чтобы весь набор данных оставался в ОЗУ".См. http://www.mongodb.org/display/DOCS/Caching для объяснения того, почему / как она использует виртуальную память так, как она это делает.

Было бы хорошо для этого приложения.Если бы ваша сортировка и фильтрация были более сложными, вы можете, например, захотеть использовать операцию Map-Reduce для создания коллекции, которая «отображает готово», но для простого упорядоченного набора дат существующие индексы будут работать просто отлично.

2 голосов
/ 04 февраля 2011

MongoDB использует mmap для отображения документов в виртуальную память (не физическую RAM).Mongo не требует, чтобы весь набор данных находился в ОЗУ, но вы хотите, чтобы ваш «рабочий набор» находился в памяти (рабочий набор должен быть подмножеством всего набора данных).

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

1 голос
/ 04 февраля 2011

@ Андрей Дж Как правило, вам требуется достаточно оперативной памяти для хранения вашего рабочего набора, это верно для MongoDB, как и для RDBMS. Так что, если вы хотите хранить последние 20 писем для всех пользователей, не заходя на диск, тогда вам нужно столько памяти. Если это превышает объем памяти в одной системе, то вы можете использовать функцию шардинга MongoDB для распределения данных по нескольким машинам, таким образом агрегируя пропускную способность памяти, ЦП и ввода-вывода машин в кластере.

@ тР MongoDB позволяет вам, как разработчику приложения, определять долговечность ваших записей - от одного узла в памяти до нескольких узлов на диске. Выбор зависит от ваших потребностей и важности данных; не все данные созданы одинаково. Кроме того, в MongoDB 1.8 вы можете указать - dur , это записывает файл журнала для всех записей. Это дополнительно повышает долговечность операций записи и ускоряет восстановление в случае сбоя.

0 голосов
/ 04 февраля 2011

И что произойдет, если ваш компьютер вылетит из-за всего, что Монго имел в памяти.Я предполагаю, что у него нет журналов, поэтому ответ, вероятно, неудача.

...