Поскольку уже есть и ответ представлен, и при этом полезный и действительный, я не хочу отвлекаться от его собственной полезности, но действительно есть моменты, которые нужно поднять, выходящие за рамки простого краткого комментария. Поэтому рассмотрим это «увеличение», которое, мы надеемся, действительно, но в первую очередь в дополнение к тому, что уже было сказано.
Истина заключается в том, чтобы по-настоящему рассмотреть «то, как ваше приложение использует данные», а также знать факторы в «изолированной среде», а также предлагаемую «контейнерную среду», которые влияют на это.
Фоновый случай
Общая рекомендация по практической рекомендации для совместного размещения mongosпроцесса вместе с экземпляром приложения состоит в том, чтобы устранить любые сетевые издержки, необходимые для взаимодействия приложения с этим mongosпроцессом. Конечно, это также «рекомендуемая практика» - указывать количество mongosэкземпляров в строке подключения приложения в случае, когда этот «ближайший» узел по какой-то причине не должен быть доступен, тогда может быть выбран другой, хотя и с возможными накладными расходами на соединение с удаленный узел.
Случай с «докером», о котором вы говорите, кажется несколько произвольным. Хотя верно и то, что одной из основных целей контейнеров (а до этого, например, BSD-джейлов или даже chroot), как правило, является достижение некоторого уровня «изоляции процессов», нет ничего действительно плохого в запуске нескольких процессов, пока вы понять последствия.
В этом конкретном случае mongosпредполагается, что он «легкий» и запускается как «дополнительная функция» к процессу приложения таким образом, что он в значительной степени является «парной» частью самого приложения. Таким образом, сами образы Docker не имеют процесса, подобного initd, но на самом деле нет ничего плохого в том, чтобы запускать контроллер процесса, такой как supervisord (например), в качестве основного процесса для контейнера, который затем дает вам точку управления процессом этот контейнер также. Такая ситуация «парных процессов» является разумным случаем, а также достаточно распространенным вопросом, что для этого есть официальная документация .
Если вы выбрали такой тип «парной» операции для развертывания, то она действительно затрагивает основную точку поддержки mongosэкземпляра в том же сетевом соединении и действительно «экземпляр сервера», как и сам сервер приложений. Это также может рассматриваться как случай, когда «весь контейнер» потерпит неудачу, тогда этот узел сам по себе будет просто недействительным. Не то, чтобы я рекомендовал это, и на самом деле вам, вероятно, все равно следует настроить соединения для поиска других mongosэкземпляров, даже если они доступны только через сетевое соединение, которое увеличивает задержку.
Зависит от версии / использования
Теперь, когда эта точка зрения сделана, другое рассмотрение здесь возвращается к первоначальному рассмотрению совместного размещения mongosпроцесса с приложением для целей задержки в сети. В версиях MongoDB до 2.6 и, в частности, в отношении таких операций, как с платформой агрегации, существовал случай, когда сетевой трафик будет намного больше и впоследствии после обработки, выполняемой mongosпроцессом обработки данных из разных сегментов. , Сейчас это не так много, так как большая часть рабочей нагрузки обработки может теперь выполняться на самих этих осколках перед тем, как «перегоняться» к «маршрутизатору».
Другой случай - это шаблоны использования вашего приложения в отношении шардинга. Это означает, является ли основная рабочая нагрузка «распределением записей» по нескольким сегментам или же подходом «разброса» при консолидации запросов на чтение. В этих сценариях
Тестируй, тестируй и тестируй снова
Таким образом, последний пункт здесь действительно говорит сам за себя и сводится к общему согласию любого здравомыслящего ответа на ваш вопрос. Это не новость для MongoDB или любого другого решения для хранения данных, но ваша фактическая среда развертывания должна быть протестирована на ее «шаблонах использования», максимально приближенных к реальной реальности, равно как и любое «модульное тестирование» ожидаемой функциональности от основных компонентов или Общие результаты должны быть проверены.
На самом деле не существует «окончательного» выражения «настроить таким образом» или «использовать таким образом», которое действительно имеет смысл, кроме тестирования того, что «действительно работает лучше» для производительности и надежности вашего приложения, как и ожидалось.
Конечно, «лучшим случаем» всегда будет не «переполнять» mongosэкземпляры запросами «многих» источников серверов приложений. Но затем, чтобы дать им некоторый естественный «паритет», который может быть распределен по рабочим нагрузкам ресурсов, имеющим, по крайней мере, «пул ресурсов», который может быть выбран, и, в идеале, в идеале во многих случаях, но устраняет необходимость вызывать дополнительный "издержки сетевого транспорта".
Это цель, но в идеале вы можете «лабораторно протестировать» различные предполагаемые конфигурации, чтобы найти решение, наиболее подходящее для вашего возможного решения по развертыванию.
Я также настоятельно рекомендую «бесплатные» (как в пиве) курсы, доступные, как уже упоминалось, и независимо от того, какой у вас уровень знаний. Я считаю, что различные источники материалов курса часто предлагают «скрытые жемчужины», чтобы дать более глубокое понимание вещей, которые вы, возможно, не рассматривали или иным образом упускали из виду. Класс M102, как упомянуто, создан и проведен Адамом Коммерфордом, которому я могу засвидетельствовать, обладает высоким уровнем знаний о крупномасштабных развертываниях MongoDB и других архитектур данных. Стоит потратить время, чтобы хотя бы по-новому взглянуть на то, что, как вы думаете, вы уже знаете.
mongos, сопоставление с тем же числом выделенных узлов должно обеспечить как минимум достаточное количествоmongosэкземпляров. Это не точная наука и зависит от ваших потребностей, но именно так я бы предпочел производственную среду.