Какое оборудование делает хороший Сервер MongoDB? Где его взять?

Предположим, вы сейчас находитесь на dell.com и покупаете сервер для запуска базы данных MongoDB для небольшого стартапа. Вам придется обрабатывать буквально десятки тысяч операций записи и чтения в минуту (но небольших объектов). Вы бы пошли на 2 процессора? Инвестировать больше в оперативную память?

Я слышал (поправьте меня, если я ошибаюсь) MongoDB обрабатывает все, что может на оперативной памяти, а затем записывает все на диск, в этом случае я должен инвестировать в ЦП с большим кешем второго уровня, вероятно,> 40 ГБ оперативной памяти. и твердотельный накопитель .. верно?

Будет ли мне лучше использовать сервер высокого класса (~ 11 309 долларов, 2 дорогих процессора, 96 ГБ ОЗУ) или 2x (~ 6 419 долларов, 2 дорогих процессора, 12 ГБ ОЗУ) серверов?

Dell в порядке или у вас есть лучшие предложения? (Я за пределами США, в Португалии)

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

Самое главное - иметь достаточно оперативной памяти, чтобы хранить ваши индексы в оперативной памяти. В противном случае ваша производительность сильно пострадает, так как ваши серверы будут работать постоянно, в то время как Mongo перемещает файлы с отображенной памятью в оперативную память и из нее. Несмотря на все это, мы не видели, как влияет скорость записи, но все остальное есть. Обработка списаний из очереди, очистка, дампы и т. Д. - все сильно ухудшается, когда ваши индексы больше не помещаются в ОЗУ.

Так что нет короткого ответа. В основном, будьте осторожны с вашими индексами. Используйте только то, что вам нужно. Держите коллекции маленькими, если можете (т.е. делите их на несколько, где можете.) Коллекции с крышками также интересны для изучения.

Очень важно использовать 64-битную машину, а не 32-битную. http://blog.mongodb.org/post/137788967/32-bit-limitations

С MongoDB вам нужна оперативная память. А потом еще немного оперативной памяти. Покупка оперативной памяти не повредит.

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

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

Интересно, будет ли кластерное решение Linux лучшей, более дешевой альтернативой?

MongoDB позволяет вам распределять данные по многим серверам. Это будет невозможно с одним, сигналящим сервером.

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

Десятки тысяч пишут в минуту - ничто. Вы можете получать 50 000 или более записей в секунду на приличном оборудовании. Аппаратные характеристики действительно зависят от того, что вы пытаетесь сделать. Вообще достаточно ОЗУ для больших баз данных и систем быстрого ввода-вывода важны для достойного процессора ...

Важно установить надежную основу для проектирования вашего оборудования. Как правило, ожидайте, что такие вопросы будут задаваться опытными людьми mongoDB, прежде чем кто-либо сможет даже ответить на ваш вопрос.

Текущая статистика приложения (если есть)

• Всего записей на сегодняшний день?
• Начальная оценка хранилища?
• Ожидаемый% роста / месяц?
• Средний размер документа?

Загрузка данных при загрузке

• Новые вставки / день, пик и среднее значение в секунду?
• Обновления / день, пик и среднее значение в секунду?
• Читает / день, пик и среднее / секунду?
• Среднее количество документов, возвращаемых по запросу: 70
• Удаляет / день, пик и среднее / секунду: нет
• Будут ли массовые загрузки / массовые обновления? Если да, то как много и как часто?
• Сколько будет разных типов документов?
• Сколько у каждого?
• Как вы ожидаете, что ваши документы будут выглядеть (образец документа)?

Шаблоны запросов и ожидания производительности

• Читать ответ SLA?
• Написать отзыв SLA?
• Является ли чтение на основе диапазона или случайным?

Ожидаемые шаблоны доступа

• Количество вторичных индексов требуется?
• Количество атрибутов?
• Условия сортировки?
• Одиночный или составной?