Como ya se ha enviado una respuesta, y una respuesta útil y válida, no quiero distraerme de su propia utilidad, pero de hecho hay puntos para plantear que van más allá de un breve comentario. Así que considere este "aumento", que es de esperar válido pero principalmente además de lo que ya se ha dicho.
La verdad es considerar realmente "cómo su aplicación utiliza los datos", y también tener en cuenta los factores en un "entorno fragmentado", así como su "entorno contenedor" propuesto que afectan esto.
El caso de fondo
La opinión general sobre la recomendación de práctica para la ubicación conjunta del mongosproceso junto con la instancia de la aplicación es obviar cualquier sobrecarga de red requerida para que la aplicación se comunique con ese mongosproceso. Por supuesto, también es una "práctica recomendada" especificar un número de mongosinstancias en la cadena de conexión de la aplicación en el caso de que el nodo "más cercano" no esté disponible por alguna razón, entonces podría seleccionarse otro, aunque con la posible sobrecarga de contactar a un nodo remoto
El caso "docker" que menciona parece algo arbitrario. Si bien es cierto que uno de los objetivos principales de los contenedores (y antes de eso, algo así como cárceles BSD o incluso chroot) es generalmente lograr cierto nivel de "aislamiento de procesos", no hay nada realmente malo en ejecutar múltiples procesos siempre y cuando entender las implicaciones
En este caso particular, mongosse pretende que sea "liviano" y se ejecute como una "función adicional" para el proceso de la aplicación de manera que sea más o menos una parte "emparejada" de la aplicación misma. Por lo tanto, las imágenes de Docker en sí mismas no tienen un proceso similar a "initd", pero en realidad no hay nada de malo en ejecutar un controlador de proceso como supervisor (por ejemplo) como el proceso principal para el contenedor que luego le da un punto de control del proceso sobre ese contenedor también. Esta situación de "procesos emparejados" es un caso razonable y también es bastante común pedir que exista documentación oficial para ello.
Si elige ese tipo de operación "emparejada" para el despliegue, entonces sí aborda el punto principal de mantener una mongosinstancia en la misma conexión de red y, de hecho, la "instancia del servidor" como el servidor de aplicaciones en sí. También se puede ver de alguna manera como un caso en el que el "contenedor completo" fallaba, entonces ese nodo en sí mismo simplemente no sería válido. No es que lo recomendaría, y de hecho, probablemente aún debería configurar las conexiones para buscar otras mongosinstancias, incluso si estas solo son accesibles a través de una conexión de red que aumenta la latencia.
Versión específica / Uso específico
Ahora que se hace ese punto, la otra consideración aquí vuelve a esa consideración inicial de ubicar el mongosproceso junto con la aplicación para fines de latencia de red. En las versiones de MongoDB anteriores a la 2.6 y específicamente con respecto a operaciones tales como el marco de agregación, entonces el caso era que habría mucho más tráfico de red y posterior después del trabajo de procesamiento realizado por el mongosproceso para tratar con datos de diferentes fragmentos . Ese no es el caso ahora, ya que una buena parte de la carga de trabajo de procesamiento ahora se puede realizar en esos fragmentos antes de "destilarlos" al "enrutador".
El otro caso son los patrones de uso de su aplicación con respecto al fragmentación. Eso significa si la carga de trabajo principal está en "distribuir las escrituras" a través de múltiples fragmentos, o de hecho es un enfoque de "dispersión-recopilación" al consolidar las solicitudes de lectura. En esos escenarios
Prueba, prueba y luego prueba de nuevo
Entonces, el punto final aquí se explica por sí mismo y se reduce al consenso básico de cualquier respuesta sensata a su pregunta. Esto no es algo nuevo para MongoDB o cualquier otra solución de almacenamiento, pero su entorno de implementación real necesita ser probado en sus "patrones de uso" tan cerca de la realidad real como cualquier "prueba unitaria" de la funcionalidad esperada de los componentes principales o Los resultados generales deben ser probados.
Realmente no hay una declaración "definitiva" que diga "configurar de esta manera" o "usar de esta manera" que tenga sentido, aparte de probar lo que "realmente funciona mejor" para el rendimiento y la confiabilidad de su aplicación como se espera.
Por supuesto, el "mejor caso" siempre será no "abarrotar" las mongosinstancias con solicitudes de "muchas" fuentes de servidores de aplicaciones. Pero luego, permitirles una "paridad" natural que se pueda distribuir por las cargas de trabajo de recursos disponibles para tener al menos "un" grupo de recursos "que se puede seleccionar, y de hecho idealmente en muchos casos, pero obviando la necesidad de inducir una necesidad adicional "gastos generales de transporte de red".
Ese es el objetivo, pero lo ideal es que pueda "probar en el laboratorio" las diferentes configuraciones percibidas para llegar a una solución "más adecuada" para su eventual solución de implementación.
También recomendaría encarecidamente los cursos "gratuitos" (como en cerveza) disponibles como ya se mencionó, y no importa cuál sea su nivel de conocimiento. Encuentro que varias fuentes de material del curso a menudo ofrecen "gemas ocultas" para dar más información sobre cosas que quizás no haya considerado o pasado por alto. La clase M102, como se mencionó, está construida y dirigida por Adam Commerford, de quien puedo afirmar que tiene un alto nivel de conocimiento sobre implementaciones a gran escala de MongoDB y otras arquitecturas de datos. Vale la pena el tiempo para al menos considerar una nueva perspectiva sobre lo que puede pensar que ya sabe.