Когда и как мы должны защищать MongoDB, когда мы привязаны к физическим машинам?
Мы поддерживаем службу поиска, которая обслуживает данные из MongoDB. Наш производственный экземпляр Mongo организован в виде набора из четырех узлов на четырех физических серверах.
База данных состоит из нескольких небольших коллекций и одной большой коллекции. Большая коллекция имеет следующие характеристики:
- количество документов: 35 миллионов
- средний размер документа: ~4,2 кБ
- размер коллекции: 151 ГБ
- Размер хранилища: 157 ГБ
В течение следующего года мы ожидаем, что количество документов в этой коллекции удвоится до ~70 миллионов, а размер коллекции увеличится вдвое.
Мне известно, что в разделе "Размер данных существующего набора данных" документа Mongo Reference Limits указано, что "Для существующих коллекций, содержащих документы, MongoDB поддерживает включение разделения для любых коллекций, которые содержат менее 256 гигабайт данных. MongoDB может быть возможность разделения коллекций объемом до 400 гигабайт в зависимости от размера документов". Следовательно, мы хотели бы осколок, прежде чем мы достигнем 256 гигабайт данных.
У нас есть некоторые ограничения на ресурсы, и мы (пока) не в состоянии виртуализировать. Тем не менее, мы находимся в состоянии купить два новых сервера, в результате чего их общее количество достигло шести производственных машин.
У меня вопрос: возможно ли разделить Mongo на два сегмента, каждый из которых представляет собой набор из трех серверов с шестью физическими серверами? Я осознаю, что в дополнение к наборам реплик нам потребуются три config серверы и mongos сервер?
Должны ли мы даже осколки? Наше текущее использование ОЗУ и количество соединений в настоящее время находятся в пределах допустимых уровней. Существуют ли другие стратегии, которые мы могли бы принять, чтобы позволить нашей базе данных расти, которая не требует шардинга?
1 ответ
1) зачем вам нужно 4 узла для набора реплик? использование четного числа узлов в наборе реплик может быть очень проблематичным, поскольку при сбое происходит выбор между узлами, чтобы решить, какой из них станет основным, прочитайте это -> http://docs.mongodb.org/manual / ядро / копия набора-выборы /
3 узла более чем достаточно, 2 фактических узла дБ и 1 маленький арбитр, который просто помогает в выборе
2) относительно кластера сегментов -> минимальное количество физических серверов для кластера с двумя сегментами с минимальным набором реплик для каждого сегмента - 9(!), Разделение выглядит следующим образом: сегмент 1(набор реплик): 2 узла данных + 1 произвольный (может быть микро экземпляр) осколок 2(набор реплик): 2 узла данных + 1 произвольный (может быть микро экземпляр) 3 сервера конфигурации (ОБЯЗАТЕЛЬНО!!) - это могут быть довольно маленькие машины - мы используем экземпляр t1.micro на amazon AWS.
Каждый осколок, который вы хотите добавить в кластер, будет стоить вам еще 3 физических узла, как указано выше.
mongos -> это клиентские экземпляры, с которыми должен взаимодействовать ваш драйвер монго приложения. Вы можете развернуть их как часть любого веб-сервера, поэтому вам не нужен отдельный компьютер.
см. это для получения дополнительной информации - http://docs.mongodb.org/manual/core/sharded-cluster-architectures-production/