Какая стандартная системная архитектура для MongoDB

Вы начинаете с как минимум 500 ГБ данных и увеличиваете скорость до 700 МБ в день. Возможно, вы захотите рассмотреть сегментирование с самого начала (возможно, только один фрагмент), чтобы вы могли управлять данными на сервере. Мы (MongoHQ) обнаружили, что 500 ГБ - это хороший верхний предел для настройки одного сервера / набора реплик. Для сегментирования потребуется, по крайней мере, один монго и 3 сервера конфигурации в дополнение к набору реплик, и вы должны найти хороший ключ шарда.

Тем не менее, вам нужно выяснить, насколько велик ваш рабочий набор, и убедиться, что у вас достаточно оперативной памяти для его хранения. Рабочий набор определяется как "часть документов + индексы, к которым вы обращаетесь в течение заданного промежутка времени", наше типичное практическое правило - около 1 ГБ памяти на 10 ГБ памяти с медленными дисками. Это сильно зависит от ваших данных и схем доступа. Твердотельные накопители становятся полезными, когда у вас есть патологический рабочий набор, и хранить все это в памяти будет дорого. Запустите mongostat для нагрузки моделирования и посмотрите на столбец "неисправности", чтобы понять, как часто БД собирается на диск.

Простой набор реплик - хорошее начало. Однако, если вы выполняете чтение из вторичного устройства, у вас действительно должна быть установка с тремя участниками, а не только две (в любом случае вам понадобится арбитр для двух). Люди попадают в беду, когда они загружают два сервера чтением, один умирает, и их приложение перегружает один оставшийся сервер. Наличие 3 меньших серверов гораздо более желательно, чем 2 больших сервера.

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

Это довольно расплывчатый вопрос, поэтому я дам несколько расплывчатый ответ. Почти любая из них является отдельной темой, поэтому не стесняйтесь использовать ее, чтобы создавать и задавать более конкретные вопросы, если что-то не понятно.

1. Читайте интенсивно - убедитесь, что все документы и индексы помещаются в оперативной памяти
2. Если это невозможно, получите твердотельные накопители, чтобы минимизировать попадание при сбое на диск
3. Высокая доступность - RAID1 или RAID10 - ваш друг, резервируйте свои данные другими способами, кроме идентификатора репликации, который вы можете
4. Не используйте master/slave, используйте наборы реплик - код master/slave устарел
5. Ubuntu 11.04 будет в порядке, пока вы устанавливаете из репозитория 10gen, а не из Ubuntu
6. Убедитесь, что вы понимаете, что такое конечная согласованность и что это означает для вашего приложения при выполнении ведомого / вторичного чтения (также посмотрите на настройки записи в выбранном вами драйвере).

Надеюсь, это поможет вам в качестве отправной точки.

Вам действительно нужно прочитать документацию MongoDB. https://docs.mongodb.com/manual/administration/

Сверху головы, вы уже ошибаетесь со своими предположениями.

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