Предположим, вы прямо сейчас находитесь на dell.com и покупаете сервер для запуска базы данных MongoDB для своего небольшого стартапа. Вам придется обрабатывать буквально десятки тысяч операций записи и чтения в минуту (но небольших объектов). Вы бы выбрали 2 процессора? Инвестировать больше в оперативную память?
Я слышал (поправьте меня, если я ошибаюсь) MongoDB максимально обрабатывает ОЗУ, а затем сбрасывает все на диск, в этом случае я должен инвестировать в ЦП с большим кешем L2, вероятно,> 40 ГБ ОЗУ и твердотельный накопитель .. верно?
Будет ли мне лучше с сервером высокого класса (~ 11 309 долларов США, 2 дорогих процессора, 96 ГБ ОЗУ) или 2 сервера (~ 6419 долларов США, 2 дорогих процессора, 12 ГБ ОЗУ)?
Dell в порядке или у вас есть предложения получше? (Я за пределами США, в Португалии)
Первоначально вам нужно увеличить объем оперативной памяти. Объем оперативной памяти, которая вам понадобится, зависит от объема данных, которые вы храните, количества коллекций, индексов этих коллекций, шаблонов доступа к данным и т. Д. Множество факторов.
Самое главное - иметь достаточно оперативной памяти для хранения индексов в оперативной памяти. В противном случае ваша производительность сильно пострадает, поскольку ваш сервер (ы) будет постоянно пейджинговать, в то время как Mongo перемещает файлы с отображением памяти в ОЗУ и из нее. Несмотря на все это, мы не видели, чтобы скорость записи влияла на скорость записи, но все остальное было. Обработка записи из очереди, сброса, дампа и т. Д. Сильно пострадает, если ваши индексы больше не помещаются в ОЗУ.
Так что короткого ответа нет. В принципе, будьте внимательны со своими индексами. Используйте только то, что вам нужно. Сохраняйте коллекции небольшими, если можете (то есть разбивайте их на несколько, где можете). Также интересно изучить закрытые коллекции.
Очень важно использовать 64-битную машину, а не 32-битную. http://blog.mongodb.org/post/137788967/32-bit-limitations
С MongoDB вам нужна оперативная память. А потом еще немного ОЗУ. Покупка оперативной памяти не повредит.
Если вы находитесь на этапе покупки производственного оборудования, то приложение, которое вы используете, уже должно быть написано, верно? Так что запустите приложение на имеющемся у вас оборудовании и измерьте показатели. Постепенно меняйте некоторые компоненты и снимайте больше метрик. Когда вы закончите, вы будете знать, какие точки внимания наиболее важны для вашего приложения и сценария.
Во-первых, купите как можно больше оперативной памяти. Второй ограничивающий фактор - это скорость диска. RAID помогает. SSD помогает. Больше осколков поможет. Измерьте пропускную способность по сравнению с эффективностью диска и требуемым временем отклика, а затем решите, что делать в рамках имеющегося у вас бюджета.
Мне интересно, будет ли кластерное решение Linux лучшей и более дешевой альтернативой.
MongoDB позволяет распределять данные по множеству серверов. Это будет невозможно с одним сигнальным сервером.
Я думал, что MongoDB - это один из следующих шагов, предпринятых после того, как обнаружил, что развертывание реляционной базы данных на сигнальном сервере недостаточно хорошо масштабируется.
Десятки тысяч записей в минуту - ничто. Вы можете получить 50 000 или более записей за второй на достойном железе. Технические характеристики оборудования действительно зависят от того, что вы пытаетесь сделать. В общем, достаточно оперативной памяти для больших баз данных и быстрых систем ввода-вывода важны помимо приличного процессора ...
Перед проектированием оборудования важно установить прочную основу. Обычно ожидайте, что такие вопросы будут заданы опытными людьми mongoDB, прежде чем кто-либо даже сможет подумать об ответе на ваш вопрос.
Текущая статистика приложения (если есть)
Рабочая нагрузка приема данных
Шаблоны запросов и ожидаемая производительность
Ожидаемые шаблоны доступа