Рекомендуемая практика развертывания MongoDB на EC2 для производства?

Ответ 1

• Начните с включенного sharding, но ограничьте количество осколков тем, что вам действительно нужно. Начиная с включенного осколка, демонов монго на месте, выберите ключи осколков для соответствующих коллекций и сделать ваши запросы целенаправленными, а не глобальными как только возможно. С этого момента добавьте осколки при увеличении нагрузки. Возможным исключением является то, что вы ожидаете большого притока трафика на запуск, в этом случае вы хотите, чтобы добавить больше осколков и предварительно разделить и предварительно перемещать ваши куски в соответствующие осколки, поскольку балансировка блоков является медленным процессом.
• Такой план не нужен. Осколки могут быть добавлены и удалены на лету. Обратите внимание, что удаление осколков связано с их удалением. С этого момента займет (значительное) количество времени, прежде чем все куски будут перемещены к другим осколкам, чтобы экземпляр можно было удалить.
• Наборы реплик допускают это. Если ваши требования к долговечности не суперкритический, вы можете добиться некоторой экономической эффективности путем хостинга несколько арбитров в одном экземпляре, а не полный 3 член repsets. Также обратите внимание, что повторы будут улучшать производительность чтения для возможных согласованных согласований запросов с использованием "slaveOk" флаг. Кроме того, вы можете подумать о достижении аналогичных уровней прочности с меньшими накладными расходами, используя восстановление на уровне диска (например, RAID10). Очевидно, что это не ломает полный отказ экземпляра.
• Разделение географического центра обработки данных всегда хорошая идея, но заметьте что производительность репликации будет значительно отличаться. Стратегии поскольку это не отличается от любой другой базы данных.

Дальнейшие примечания:

• Сетевой уровень EC2 ограничен 100 тыс. пакетов в секунду. Для небольших запросов с высокой пропускной способностью это быстро станет узким местом.
• Настройте свои объемы EBS. Работа на одном томе EBS вызовет Чрезвычайную иррациональную работу. Это становится более стабильным, поскольку большее количество томов является частью настройки RAID. Должно быть!
• Использовать экземпляры большой памяти. Мы видели значительную производительность улучшений здесь, поскольку только так много можно сделать по праву балансируя ваши индексы и сохраняя в памяти только соответствующие данные. Держать взгляд на ваши недостатки/сек в монгостате. Это страницы и, следовательно, количество раз, когда mongo должен ударить диск, чтобы поменять страницу.

Ответ 2

myNoSQL, мой самый любимый блог NoSQL, недавно опубликовал статью под названием Запуск MongoDB в облаке, в котором перечислены несколько статей о развертывании MongoDB в облаке Amazon.

• MongoDB на Amazon EC2 с объемами EBS
• MongoDB на EC2
• MongoDB в Облаке Амазонки
• Настройка наборов копий MongoDB на Amazon EC2
• MongoDB и Amazon: Почему EBS?
• Amazon EBS vs SSD: цена, производительность, QoS
• Многопользовательская и облачная производительность

Ответ 3

Уинстон, Кристина Чодорову "Масштабирование MongoDB" - это то, что вы хотите:

http://oreilly.com/catalog/0636920018308

Как я понимаю,

1) Вам нужны наборы реплик из 3 или более экземпляров (некоторые нечетные числа) для каждого осколка, плюс, возможно, некоторые временные экземпляры в каждом осколке, чтобы действовать как резервная копия

2) Просто добавьте их в кластер - Mongo будет медленно перемещать осколки на новые узлы, пока кластер не будет сбалансирован

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

4) Добавление экземпляров с задержкой по времени к каждому набору реплик - хорошая идея, особенно если (как вы говорите), они распределены географически или если они находятся на нескольких хостинг-провайдерах (то есть, если ваши главные серверы включены Amazon, вы можете поместить резервные копии в Rackspace). Если большая часть набора реплик опускается, остальные узлы не будут автоматически выбирать новый основной, но вы можете сделать это вручную в такой катастрофе.

Ответ 4

1) Я бы начал с нескольких осколков, если вы не знаете, что вам определенно нужно больше.
2) Трудная часть добавления дополнительных осколков - это время, необходимое для перебалансировки. В зависимости от ваших данных и нагрузки может потребоваться несколько дней для восстановления всего осколка. Поэтому вы хотите запланировать добавление осколков во время низкой загрузки
3) Каждый осколок должен быть как минимум 2 + 1 реплики с репликами, распределенными по доступным зонам.
4) Если вы заинтересованы в аварийном восстановлении, вы должны распространять свои реплики по регионам, а не через зоны доступности. Подробнее здесь - Рекомендации EC2. Также не забудьте правильно настроить приоритет своих реплик, если вы распространяете реплики по географическим регионам.