Como já existe uma resposta, e uma útil e válida, não quero me distrair de sua própria utilidade, mas há de fato pontos para elevar isso que vão muito além de apenas um breve comentário. Portanto, considere este "aumento", que é esperançosamente válido, mas principalmente além do que já foi dito.
A verdade é realmente considerar "como seu aplicativo usa os dados" e também estar ciente dos fatores em um "ambiente fragmentado", bem como do "ambiente de contêiner" proposto que afeta isso.
O caso de fundo
A abordagem geral da recomendação prática para co-localizar o mongos
processo junto com a instância do aplicativo é evitar qualquer sobrecarga de rede necessária para que o aplicativo se comunique com esse mongos
processo. Obviamente, também é uma "prática recomendada" especificar um número de mongos
instâncias na cadeia de conexão do aplicativo no caso em que o nó "mais próximo" não esteja disponível por algum motivo, então outro poderá ser selecionado, embora com a possível sobrecarga de contato com um nó remoto.
O caso "docker" que você menciona parece um tanto arbitrário. Embora seja verdade que um dos principais objetivos dos contêineres (e antes disso, algo como cadeias BSD ou mesmo chroot) geralmente seja atingir algum nível de "isolamento do processo", não há nada realmente errado em executar vários processos, desde que você entender as implicações.
Nesse caso em particular, ele mongos
deve ser "leve" e ser executado como uma "função adicional" no processo do aplicativo, de forma que é praticamente uma parte "emparelhada" do próprio aplicativo. Portanto, as próprias imagens do docker não possuem um processo do tipo "initd", mas não há realmente nada de errado em executar um controlador de processo como supervisord (por exemplo) como o processo principal do contêiner, o que lhe dá um ponto de controle do processo. esse recipiente também. Essa situação de "processos emparelhados" é um caso razoável e também é bastante comum pedir que exista documentação oficial para isso.
Se você escolher esse tipo de operação "emparelhada" para implantação, ela realmente abordará o ponto principal de manter uma mongos
instância na mesma conexão de rede e, de fato, "instância do servidor" que o próprio servidor de aplicativos. Também pode ser visto de alguma forma como um caso em que o "contêiner inteiro" falharia, então esse nó em si seria simplesmente inválido. Não que eu o recomende e, na verdade, você provavelmente ainda deve configurar conexões para procurar outras mongos
instâncias, mesmo que estas sejam acessíveis apenas por uma conexão de rede que aumente a latência.
Versão específica / Uso específico
Agora que esse ponto foi levantado, a outra consideração aqui volta à consideração inicial de co-localizar o mongos
processo com o aplicativo para fins de latência de rede. Nas versões do MongoDB anteriores à 2.6 e especificamente em operações como a estrutura de agregação, havia o caso de haver muito mais tráfego de rede e subsequente trabalho de processamento após o processamento realizado pelo mongos
processo para lidar com dados de diferentes shards . Esse não é o caso agora, já que boa parte da carga de trabalho de processamento agora pode ser executada nesses shards antes de "destilar" o "roteador".
O outro caso são os próprios padrões de uso do aplicativo em relação ao sharding. Isso significa se a carga de trabalho principal está em "distribuir as gravações" entre vários shards, ou mesmo sendo uma abordagem de "coleta dispersa" na consolidação de solicitações de leitura. Nesses cenários
Teste, Teste e Teste novamente
Portanto, o ponto final aqui é realmente autoexplicativo e se resume ao consenso básico de qualquer resposta sensata à sua pergunta. Isso não é novidade para o MongoDB ou qualquer outra solução de armazenamento, mas seu ambiente de implantação real precisa ser testado em seus "padrões de uso" tão próximos da realidade real quanto em qualquer "teste de unidade" da funcionalidade esperada dos componentes principais ou os resultados gerais precisam ser testados.
Realmente não existe uma declaração "definitiva" para dizer "configurar desta maneira" ou "usar dessa maneira" que realmente faz sentido, além de testar o que "realmente funciona melhor" para o desempenho e a confiabilidade do aplicativo, conforme o esperado.
Obviamente, o "melhor caso" sempre será não "agrupar" as mongos
instâncias com solicitações de "muitas" fontes do servidor de aplicativos. Mas, então, permitir a eles alguma "paridade" natural que pode ser distribuída pelas cargas de trabalho de recursos disponíveis para ter "pelo menos" um "conjunto de recursos" que pode ser selecionado e, de fato, idealmente em muitos casos, mas evitando a necessidade de induzir um adicional "sobrecarga de transporte de rede".
Esse é o objetivo, mas, idealmente, você pode "testar em laboratório" as diferentes configurações percebidas para obter uma solução "mais adequada" para sua eventual solução de implantação.
Eu também recomendaria fortemente os cursos "gratuitos" (como na cerveja) disponíveis, como já mencionado, e independentemente do seu nível de conhecimento. Acho que várias fontes de material do curso geralmente oferecem "joias escondidas" para fornecer mais informações sobre coisas que você pode não ter considerado ou ignorado. A classe M102, conforme mencionado, é construída e conduzida por Adam Commerford, para quem posso atestar que possui um alto nível de conhecimento em implantações em larga escala do MongoDB e outras arquiteturas de dados. Vale a pena considerar pelo menos uma nova perspectiva sobre o que você acha que já sabe.