Confronto tra l'allocazione delle risorse per i membri del Replica Set e i nodi di Sharding

La pianificazione delle risorse di MongoDB cambia drasticamente quando si passa da un singolo replica set a un cluster shardato. Due architetture principali facilitano questi obiettivi: Replica Set e Cluster Shardati. Sebbene entrambi siano fondamentali per le distribuzioni MongoDB di livello produttivo, le loro strategie di allocazione delle risorse sottostanti differiscono significativamente, influenzando direttamente la progettazione dell'infrastruttura e i costi.

Un replica set concentra l'intero set di dati e la maggior parte della pressione di scrittura su un primario. Un cluster shardato distribuisce i dati tra i replica set degli shard, ma aggiunge router mongos e server di configurazione che necessitano anch'essi di capacità e monitoraggio.

Comprensione delle strategie di distribuzione di MongoDB

Prima di addentrarci nell'allocazione delle risorse, riepiloghiamo brevemente i ruoli di ciascun componente in un Replica Set e in un Cluster Shardato.

Replica Set: Alta disponibilità e ridondanza dei dati

Un replica set MongoDB è un gruppo di istanze mongod che mantengono lo stesso set di dati. Ciò fornisce alta disponibilità e ridondanza dei dati. Un replica set è tipicamente composto da:

Nodo Primario: L'unico nodo che riceve tutte le operazioni di scrittura. Registra tutte le modifiche nel suo log delle operazioni (oplog). Può esserci un solo primario in un replica set in un dato momento.
Nodi Secondari: Replicano l'oplog del primario e applicano queste modifiche ai propri set di dati, garantendo la coerenza dei dati. I nodi secondari possono servire operazioni di lettura, a seconda delle impostazioni di preferenza di lettura, e possono essere eletti come primario se il primario corrente diventa non disponibile.
Nodo Arbitro: Partecipa alle elezioni per determinare il primario ma non memorizza dati. Gli arbitri consumano risorse minime e possono essere utilizzati per aggiungere un voto quando non è possibile distribuire un altro membro con dati. Non prevengono tutti i problemi di elezione e dovrebbero essere usati con parsimonia.

Cluster Shardati: Scalabilità orizzontale

Lo sharding è il metodo di MongoDB per distribuire i dati su più macchine. Ciò consente la scalabilità orizzontale per gestire grandi set di dati e operazioni ad alto throughput che un singolo replica set non può gestire. Un cluster shardato comprende diversi componenti chiave:

Mongos (Router di Query): Fungono da interfaccia tra le applicazioni client e il cluster shardato. Instradano le query agli shard appropriati, aggregano i risultati e gestiscono le connessioni.
Server di Configurazione (CSRS): Memorizzano i metadati del cluster, inclusi gli intervalli di dati che risiedono su quali shard (la 'mappa degli shard'). I server di configurazione sono distribuiti come un replica set (Config Server Replica Set - CSRS) per l'alta disponibilità.
Shard: Ogni shard è esso stesso un replica set che contiene un sottoinsieme dei dati del cluster. I dati sono distribuiti tra questi shard in base a una chiave di shard.

Allocazione delle risorse per i membri del Replica Set

I requisiti di risorse per i membri del replica set variano significativamente in base al loro ruolo e al carico di lavoro complessivo.

Nodo Primario

Il nodo primario è il membro più critico e ad alta intensità di risorse di un replica set, poiché gestisce tutte le operazioni di scrittura e tipicamente la maggior parte delle operazioni di lettura.

CPU: Alta. Carichi di lavoro pesanti in scrittura, pipeline di aggregazione complesse, operazioni di indicizzazione e la gestione di molte connessioni simultanee richiedono una potenza CPU significativa. Se la tua applicazione aggiorna frequentemente i documenti o esegue query intensive, la CPU del primario può diventare rapidamente un collo di bottiglia.
RAM: Critica. Il motore di archiviazione WiredTiger di MongoDB si basa fortemente sulla RAM per la sua cache. Il primario necessita di RAM sufficiente per mantenere in memoria i dati e gli indici a cui si accede frequentemente, al fine di ridurre al minimo l'I/O su disco. Una raccomandazione comune è allocare RAM sufficiente per contenere il tuo working set (i dati e gli indici attivamente utilizzati dalle tue applicazioni) più un buffer.
Archiviazione: IOPS e throughput elevati. Tutte le operazioni di scrittura colpiscono il disco del primario, inclusa la journaling. È essenziale una memoria veloce (SSD/NVMe) con IOPS elevati (Input/Output Operations Per Second) per evitare che la latenza di scrittura diventi un collo di bottiglia. La capacità deve essere sufficiente per l'intero set di dati e la sua crescita, più lo spazio per l'oplog.

Nodi Secondari

I nodi secondari replicano i dati dal primario e possono servire richieste di lettura, scaricando il primario. Le loro esigenze di risorse sono spesso simili a quelle del primario, specialmente se gestiscono letture.

CPU: Da Moderata ad Alta. L'utilizzo della CPU dipende dal tasso di replica e dal carico di lavoro di lettura. Se i secondari gestiscono una parte significativa delle letture, i loro requisiti CPU possono avvicinarsi a quelli del primario. Se principalmente per replica e failover, l'utilizzo della CPU sarà inferiore ma comunque importante per applicare efficientemente le voci dell'oplog.
RAM: Critica. Simile al primario, i secondari mantengono una cache WiredTiger e necessitano di RAM sufficiente per contenere il working set al fine di applicare efficientemente le voci dell'oplog e servire le letture senza eccessivo I/O su disco. Idealmente, la cache di un secondario dovrebbe rispecchiare quella del primario per prestazioni consistenti durante il failover.
Archiviazione: IOPS e throughput elevati. I secondari devono tenere il passo con le scritture del primario applicando le voci dell'oplog. Anche questo richiede prestazioni I/O elevate. La capacità deve essere identica a quella del primario, poiché memorizzano una copia completa dei dati.

Suggerimento: Assicurati che i nodi secondari siano provisionati in modo simile al primario. Ciò garantisce un failover fluido e prestazioni consistenti quando un secondario diventa primario.

Nodo Arbitro

Gli arbitri sono nodi leggeri esclusivamente per partecipare alle elezioni. Non memorizzano dati né servono operazioni di lettura/scrittura.

CPU: Molto Bassa. Gli arbitri eseguono un calcolo minimo relativo ai protocolli di elezione.
RAM: Molto Bassa. Richiede solo memoria sufficiente per l'overhead di base del processo mongod e lo stato delle elezioni.
Archiviazione: Molto Bassa. Memorizza solo file di configurazione e log minimi, nessun file di dati.

Avvertenza: Non eseguire mai un'applicazione o altri processi di database su un nodo arbitro. Dovrebbe essere un'istanza dedicata e minima per garantire la sua disponibilità per le elezioni e prevenire la contesa di risorse.

Allocazione delle risorse per i componenti di Sharding

I cluster shardati introducono componenti aggiuntivi, ciascuno con profili di risorse unici, portando a una strategia di allocazione delle risorse più distribuita e complessa.

Mongos (Router di Query)

Le istanze mongos sono processi di routing senza stato. Non memorizzano dati ma coordinano le operazioni tra gli shard.

CPU: Da Moderata ad Alta. L'utilizzo della CPU scala con il numero di connessioni client, il lavoro di routing delle query, le query scatter-gather e il lavoro di merge dell'aggregazione che mongos deve coordinare. È possibile aggiungere più istanze mongos per gestire carichi più elevati.
RAM: Moderata. Utilizzata principalmente per la gestione delle connessioni, la memorizzazione nella cache dei metadati dai server di configurazione (mappa degli shard) e i buffer temporanei di aggregazione. Non è critica come i nodi con dati, ma una RAM sufficiente previene lo swapping e garantisce tempi di risposta rapidi.
Archiviazione: Molto Bassa. Vengono memorizzati solo i log. Gli SSD locali sono solitamente più che sufficienti.

Suggerimento: Per prestazioni ottimali, distribuisci le istanze mongos vicino ai tuoi server applicativi per ridurre al minimo la latenza di rete.

Server di Configurazione (Config Server Replica Set - CSRS)

I server di configurazione sono cruciali per il funzionamento del cluster shardato, memorizzando i metadati sullo stato del cluster. Sono sempre distribuiti come un replica set (CSRS).

CPU: Moderata. L'utilizzo della CPU può aumentare durante le migrazioni di chunk, il ribilanciamento degli shard o gli aggiornamenti frequenti dei metadati. Sebbene non sia elevato come quello di un primario con dati, una prestazione consistente è vitale.
RAM: Da Moderata ad Alta. Necessita di RAM sufficiente per mantenere in memoria i metadati critici del cluster. La dimensione dei metadati dipende dal numero di shard, chunk e database. Una RAM insufficiente può degradare gravemente le prestazioni e la stabilità del cluster.
Archiviazione: IOPS e capacità moderati. Sebbene la dimensione dei metadati sia generalmente inferiore ai dati utente, gli aggiornamenti alla mappa degli shard e ad altre informazioni sullo stato del cluster possono essere frequenti, richiedendo prestazioni I/O decenti. La capacità deve accogliere la crescita dei metadati e dell'oplog.

Avvertenza: Le prestazioni e la disponibilità dei tuoi server di configurazione sono fondamentali. Qualsiasi degrado può paralizzare l'intero cluster shardato. Provisionali con un'infrastruttura altamente affidabile e performante.

Membri dello Shard (Replica Set con Dati)

Ogni shard è un replica set autonomo, che memorizza un sottoinsieme dei dati totali del cluster. Pertanto, i requisiti di risorse per i nodi primario, secondario e arbitro all'interno di ciascuno shard sono simili per natura a un replica set autonomo, ma scalati per la porzione di dati che contengono.

CPU: Alta per il primario, da Moderata ad Alta per i secondari. Il primario di ogni shard gestisce tutte le scritture e potenzialmente le letture per il suo sottoinsieme di dati. Le richieste sono proporzionali al carico di lavoro instradato a quello specifico shard.
RAM: Critica per primario e secondari. Il mongod di ogni shard necessita di RAM sufficiente per la sua cache WiredTiger, proporzionale al working set dei dati che memorizza. Questo è cruciale per le prestazioni all'interno del suo segmento di dati.
Archiviazione: IOPS e throughput elevati per primario e secondari. Simile a un replica set autonomo, è richiesta una memoria veloce per gestire scritture, letture e replicazione per il sottoinsieme di dati dello shard. La capacità deve essere sufficiente per la porzione di dati dello shard e la sua crescita.

Differenza Chiave: Mentre un singolo replica set di shard ha requisiti simili a un replica set autonomo, il cluster shardato complessivo distribuisce i dati totali e il carico di lavoro su più di tali replica set. Ciò significa che la somma delle risorse su tutti gli shard sarà significativamente maggiore di un singolo replica set scalato verticalmente.

Confronto dell'allocazione delle risorse: Replica Set vs. Cluster Shardato

Caratteristica	Replica Set (Autonomo)	Cluster Shardato
Scopo	Alta Disponibilità, Ridondanza Dati, Scalabilità Moderata	Scalabilità Orizzontale, Set di Dati Molto Grandi, Alto Throughput
Nodi Totali	Comunemente 3 membri con dati; arbitri solo quando necessario	3 Server di Configurazione + N Replica Set di Shard (solitamente 3+ membri ciascuno) + M istanze Mongos
CPU	Il primario gestisce tutta la CPU di scrittura. I secondari gestiscono la CPU di lettura. Arbitro minimo.	Distribuita tra `mongos`, Server di Configurazione e più Primari di Shard. CPU totale complessivamente più alta.
RAM	Primario e Secondari necessitano di RAM per l'intero working set.	Ogni Primario/Secondario di Shard necessita di RAM per il suo sottoinsieme del working set. I server di configurazione necessitano di RAM per i metadati. RAM totale complessivamente più alta.
Archiviazione	Primario e Secondari necessitano di capacità e IOPS per l'intero set di dati.	Ogni Primario/Secondario di Shard necessita di capacità e IOPS per il suo sottoinsieme del set di dati. I server di configurazione necessitano di IOPS/capacità moderati. Archiviazione totale complessivamente più alta.
Collo di Bottiglia	Nodo primario per le scritture; limiti di risorse della singola macchina.	Qualsiasi componente (`mongos`, server di configurazione o un singolo shard) può diventare un collo di bottiglia se sotto-provisionato.
Complessità	Relativamente più semplice da configurare e gestire.	Significativamente più complesso da pianificare, distribuire e gestire.
Costo	Costo infrastrutturale inferiore per scala moderata.	Costo infrastrutturale più elevato a causa di più istanze e natura distribuita.

Considerazioni Pratiche e Best Practice

Analisi del Carico di Lavoro: Comprendi a fondo i pattern di lettura/scrittura della tua applicazione, le proiezioni di crescita dei dati e la complessità delle query. Questo è il singolo fattore più importante nella pianificazione delle risorse.
Il Monitoraggio è Fondamentale: Implementa un monitoraggio completo per tutti i componenti MongoDB (CPU, RAM, I/O disco, rete, metriche del database come l'utilizzo della cache WiredTiger, il ritardo dell'oplog, i tempi di query). Questo aiuta a identificare i colli di bottiglia e consente una scalabilità proattiva.
Prestazioni di Rete: Per i cluster shardati, la latenza di rete e la larghezza di banda tra mongos, server di configurazione e shard sono critiche. La comunicazione inter-shard e le operazioni di bilanciamento dei dati possono essere fortemente influenzate da scarse prestazioni di rete.
Risorse Dedicata: Ogni processo mongod, che sia primario, secondario o membro di shard, dovrebbe essere eseguito su hardware dedicato o su una macchina virtuale dedicata. Evita la co-ubicazione con server applicativi o altre istanze di database per prevenire la contesa di risorse.
Cloud vs. On-Premise: I provider cloud offrono flessibilità per scalare facilmente le risorse. Tuttavia, assicurati che i tipi di istanza scelti soddisfino i requisiti di IOPS e throughput, specialmente per le operazioni ad alta intensità di archiviazione.
Test e Benchmarking: Testa sempre la tua infrastruttura pianificata con carichi di lavoro realistici prima di passare alla produzione. Questo aiuta a convalidare le tue ipotesi di allocazione delle risorse.

Conclusione

Usa un replica set quando il tuo working set, il tasso di scrittura e l'archiviazione si adattano comodamente a una singola classe di nodo con dati. Passa allo sharding quando hai bisogno di scalabilità orizzontale, ma metti in conto le parti mobili extra: replica set di shard, server di configurazione, router, capacità di rete e più test operativi.