Я знаю, что этот вопрос слишком расплывчатый, поэтому я хотел бы добавить некоторые ключевые цифры, чтобы дать представление о том, каков сценарий
Size of each document size - 360KB
Total documents - 1.5 million
Document created/day - 2k
read intensive - YES
Availability requirement - HIGH
Принимая во внимание эти требования, я считаю, что вот какой должна быть архитектура, но не слишком уверен, пожалуйста, поделитесь своим опытом и укажите мне правильное направление.
2 Linux Boxes (Ubuntu 11 each on a different rack setup for availability)
64-bit Mongo Database
1 master (for read/write) and 1 slave (read-only with replication ON)
Sharding not needed at this point in time
Вы начинаете с не менее 500 ГБ данных и растете со скоростью ~ 700 МБ в день. Возможно, вы захотите рассмотреть возможность сегментирования с самого начала (возможно, только один сегмент), чтобы сохранить управляемость данными для каждого сервера. Мы (MongoHQ) обнаружили, что 500 ГБ - хороший верхний предел для настройки одного сервера / набора реплик. Шардинг потребует, чтобы вы запустили по крайней мере один mongos и 3 сервера конфигурации в дополнение к набору реплик и провели исследование, чтобы выбрать хороший ключ шарда.
Тем не менее, вам нужно выяснить, насколько велик ваш рабочий набор, и убедиться, что у вас достаточно оперативной памяти для его хранения. Рабочий набор определяется как «часть документов + индексов, к которой вы получаете доступ в течение заданного промежутка времени», наше типичное практическое правило - около 1 ГБ памяти на 10 ГБ хранилища с медленными дисками. Однако это в значительной степени зависит от ваших данных и шаблонов доступа. Твердотельные накопители становятся полезными, когда у вас патологический рабочий набор, и хранить все это в памяти было бы дорого. Бегать монгостат против нагрузки моделирования и посмотрите на столбец «неисправности», чтобы получить представление о том, как часто БД записывается на диск.
Простой набор реплик - хорошее начало. Однако, если вы выполняете чтение с вторичного сервера, вам действительно нужна установка из трех участников, а не только из двух (вам в любом случае понадобится арбитр для двоих). У людей возникают проблемы, когда они загружают два сервера чтением, один умирает, и их приложение перегружает один оставшийся сервер. Намного желательнее иметь 3 сервера меньшего размера, чем 2 сервера большего размера.
Вторичные чтения также могут вызвать проблемы с приложением. Вы должны убедиться, что ваше приложение может справиться с любой задержкой репликации, с которой вы можете столкнуться. Вы наверное не столкнется с этим сразу, но это произойдет, если вы когда-нибудь отключите вторичный сервер для обслуживания и прочтете его, прежде чем он успеет наверстать упущенное.
Это довольно расплывчатый вопрос, поэтому я дам несколько расплывчатый ответ. Практически любой из них - отдельная тема, поэтому не стесняйтесь использовать ее для создания и задания более конкретных вопросов, если что-то неясно.
Надеюсь, это поможет вам в качестве отправной точки.
Вам действительно нужно прочитать документацию MongoDB. https://docs.mongodb.com/manual/administration/
Вне моей головы, вы уже плохо начали свои предположения.
Наборы реплик - это как минимум кластеры из трех узлов. Кроме того, не обманывайтесь предположением, что вторичные узлы могут быть построены с меньшим оборудованием; Вторичные серверы кластера, доступные только для чтения, часто должны работать более интенсивно, чем первичные серверы, доступные только для записи, потому что они оба запрашиваются, а также получают и обрабатывают обновления от первичных.