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