Dato che c'è già e risposta inviata, e utile e valida, non voglio distrarre dalla sua stessa utilità, ma ci sono davvero dei punti da sollevare che vanno ben oltre un breve commento. Quindi considera questo "aumento", che si spera sia valido ma soprattutto in aggiunta a quanto è già stato detto.
La verità è davvero considerare "come l'applicazione utilizza i dati" e anche essere consapevoli dei fattori in un "ambiente condiviso" così come il "ambiente contenitore" proposto che influisce su questo.
Il caso di fondo
L'opinione generale sulla raccomandazione pratica per la collocazione congiunta del mongosprocesso insieme all'istanza dell'applicazione è quella di ovviare a qualsiasi sovraccarico di rete necessario affinché l'applicazione possa comunicare con quel mongosprocesso. Naturalmente è anche "pratica raccomandata" specificare un numero di mongosistanze nella stringa di connessione dell'applicazione nel caso in cui quel nodo "più vicino" non dovesse essere disponibile per qualche motivo, quindi potrebbe essere selezionato un altro, anche se con il possibile sovraccarico di contattare un nodo remoto.
Il caso "docker" menzionato sembra in qualche modo arbitrario. Mentre è vero che uno degli obiettivi primari dei container (e prima ancora, qualcosa come jail BSD o persino chroot) è generalmente quello di raggiungere un certo livello di "isolamento dei processi", non c'è nulla di veramente sbagliato nell'esecuzione di più processi finché capire le implicazioni.
In questo caso particolare mongossi intende che è "leggero" ed eseguito come "funzione aggiuntiva" per il processo dell'applicazione in modo che sia praticamente una parte "accoppiata" dell'applicazione stessa. Quindi le stesse immagini docker non hanno un processo simile a "initd", ma non c'è davvero nulla di sbagliato nell'esecuzione di un controller di processo come supervisord (ad esempio) come processo principale per il contenitore che offre quindi un controllo del processo anche quel contenitore. Questa situazione di "processi accoppiati" è un caso ragionevole e anche una richiesta abbastanza comune che ci sia documentazione ufficiale per esso.
Se si è scelto quel tipo di operazione "accoppiata" per la distribuzione, si rivolge effettivamente al punto principale di mantenere mongosun'istanza sulla stessa connessione di rete e in effetti "istanza del server" del server delle applicazioni stesso. Può anche essere visto in qualche modo come un caso in cui "l'intero contenitore" avrebbe dovuto fallire, quindi quel nodo in sé sarebbe semplicemente non valido. Non che lo consiglierei, e in effetti probabilmente dovresti comunque configurare le connessioni per cercare altre mongosistanze anche se queste sono accessibili solo tramite una connessione di rete che aumenta la latenza.
Versione specifica / Utilizzo specifico
Ora che è stato sottolineato questo punto, l'altra considerazione qui ritorna a quella considerazione iniziale della collocazione congiunta del mongosprocesso con l'applicazione ai fini della latenza della rete. Nelle versioni di MongoDB precedenti alla 2.6 e in particolare per quanto riguarda le operazioni come nel quadro di aggregazione, si è verificato che ci sarebbe stato molto più traffico di rete e successivamente dopo l'elaborazione del lavoro eseguito dal mongosprocesso per gestire i dati provenienti da frammenti diversi . Questo non è più il caso ora, poiché una buona parte del carico di lavoro di elaborazione può ora essere eseguita su quei frammenti stessi prima di "distillare" sul "router".
L'altro caso riguarda i modelli di utilizzo dell'applicazione in relazione allo sharding. Ciò significa se il carico di lavoro principale consiste nel "distribuire le scritture" su più frammenti, o in realtà essere un approccio "scatter-gather" nel consolidamento delle richieste di lettura. In quegli scenari
Prova, prova e quindi prova di nuovo
Quindi il punto finale qui è davvero autoesplicativo, e si riduce al consenso di base di qualsiasi risposta sana alla tua domanda. Questa non è una novità per MongoDB o qualsiasi altra soluzione di archiviazione, ma l'ambiente di distribuzione effettivo deve essere testato sui suoi "modelli di utilizzo" vicini alla realtà reale tanto quanto qualsiasi "test unitario" della funzionalità prevista dai componenti principali o i risultati complessivi devono essere testati.
Non esiste in realtà un'affermazione "definitiva" per dire "configura in questo modo" o "usa in questo modo" che ha effettivamente senso a parte testare ciò che "funziona davvero meglio" per le prestazioni e l'affidabilità dell'applicazione come previsto.
Naturalmente il "caso migliore" sarà sempre quello di non "affollare" le mongosistanze con richieste da "molte" fonti del server delle applicazioni. Ma poi per consentire loro una "parità" naturale che può essere distribuita dai carichi di lavoro delle risorse disponibili per avere "almeno" un "pool di risorse" che può essere selezionato, e anzi idealmente in molti casi ma ovviando alla necessità di indurre un ulteriore "overhead del trasporto di rete".
Questo è l'obiettivo, ma idealmente puoi "testare in laboratorio" le diverse configurazioni percepite per arrivare a una soluzione "più adatta" per la tua eventuale soluzione di distribuzione.
Consiglio vivamente anche i corsi "gratuiti" (come nella birra) disponibili come già accennato, e non importa quale sia il tuo livello di conoscenza. Trovo che varie fonti di materiale didattico spesso offrano "gemme nascoste" per fornire maggiori informazioni su cose che potresti non aver considerato o altrimenti trascurato. La Classe M102, come detto, è costruita e condotta da Adam Commerford per il quale posso attestare che ha un alto livello di conoscenza su implementazioni su larga scala di MongoDB e altre architetture di dati. Vale la pena dedicare almeno una prospettiva nuova a ciò che potresti pensare di sapere già.