Migliori Pratiche per Ottimizzare le Prestazioni di Lettura nei Replica Set

I replica set MongoDB offrono alta disponibilità, ma non rendono automaticamente le letture più veloci. Se la tua applicazione invia ogni query al primario, utilizza indici deboli o legge da secondari in ritardo, gli utenti lo percepiranno come pagine lente e dati obsoleti.

Buone prestazioni di lettura derivano dalla scelta della giusta preferenza di lettura, dall'abbinamento del livello di coerenza alla consistenza di cui hai bisogno, dal monitoraggio del ritardo di replica e dalla correzione prioritaria delle query lente.

Comprendere il Percorso di Lettura nei Replica Set

In una distribuzione standard di replica set, un membro è designato come primario, gestendo tutte le scritture. I membri rimanenti sono secondari, che replicano asincronamente i dati dal primario. Le letture dell'applicazione possono essere indirizzate al primario o distribuite tra i secondari, a seconda della configurazione.

Ottimizzare le letture significa bilanciare la necessità di una consistenza immediata dei dati (che spesso richiede la lettura dal primario) con il desiderio di scaricare il traffico dal primario (leggendo dai secondari).

1. Uso Strategico dei Livelli di Coerenza

Il Livello di Coerenza definisce il grado di consistenza dei dati richiesto per le operazioni di lettura. Impostare un livello di coerenza eccessivamente rigoroso quando uno più rilassato è sufficiente è una causa comune di latenza di lettura, poiché potrebbe forzare l'operazione ad attendere conferme da più nodi.

Livelli di Coerenza Disponibili

MongoDB offre diversi livelli di coerenza, ognuno dei quali scambia latenza per durabilità/consistenza:

Livello di Coerenza	Descrizione	Caso d'Uso
majority	Restituisce i dati riconosciuti come impegnati dalla maggioranza dei nodi votanti. Predefinito standard.	Letture per scopi generali che richiedono alta durabilità.
local	Restituisce i dati più recenti disponibili sul membro da cui si legge, indipendentemente dalla conferma di scrittura.	Letture che possono tollerare dati leggermente obsoleti (es. contatori di dashboard).
linearizable	Legge dal primario e riflette tutte le scritture riconosciute prima dell'inizio della lettura. Richiede readConcern: "linearizable" e write concern di maggioranza per le scritture pertinenti.	Letture rare che devono osservare lo stato riconosciuto più recente, come i controlli di proprietà dei lock.

Suggerimento per l'Ottimizzazione: Impostazione Predefinita su local o majority

Per letture non critiche (come il caricamento di dati di configurazione aggiornati raramente o risultati memorizzati nella cache), utilizza il livello di coerenza local sui secondari. Questo evita qualsiasi ritardo di sincronizzazione.

Esempio: Impostazione del Livello di Coerenza a Livello di Sessione

// Imposta il livello di coerenza su 'local' per questa sessione specifica
const session = mongoClient.startSession({ readConcern: { level: "local" } });

// Operazione di find utilizzando la sessione
db.collection('mydata').find().session(session).toArray();

Avvertenza: Leggere con livello di coerenza local su un secondario può restituire dati obsoleti rispetto al primario.

2. Distribuzione delle Letture tra i Secondari

Per impostazione predefinita, MongoDB indirizza le letture al primario. Per scalare la capacità di lettura, devi indirizzare esplicitamente le letture ai secondari utilizzando le impostazioni di Preferenza di Lettura.

Comprendere la Preferenza di Lettura

La Preferenza di Lettura determina quali membri del replica set sono idonei a soddisfare le richieste di lettura e in quale ordine devono essere scelti.

Preferenze di Lettura comuni includono:

• primary: (Predefinito) Solo il primario è idoneo.
• primaryPreferred: Prova prima il primario; passa a un secondario se il primario non è disponibile.
• secondary: Solo i secondari sono idonei. Se nessun secondario è disponibile, l'operazione fallisce.
• secondaryPreferred: Preferisce i secondari; passa al primario se nessun secondario è disponibile.
• nearest: Sceglie il membro (primario o secondario) con la latenza di rete più bassa verso il client.

Suggerimento per l'Ottimizzazione: Utilizzo di secondaryPreferred o nearest

Per la maggior parte delle applicazioni con carico di lettura elevato, l'utilizzo di secondaryPreferred consente di distribuire il carico delle query su tutti i secondari disponibili, riducendo significativamente il carico sul primario.

Se hai server applicativi geograficamente distribuiti, nearest è spesso la scelta migliore, poiché minimizza la latenza di rete per il client, anche se occasionalmente colpisce il primario.

Esempio: Connessione con secondaryPreferred

Quando ti connetti al driver della tua applicazione, specifica la preferenza di lettura:

const uri = "mongodb://host1,host2,host3/?replicaSet=rs0&readPreference=secondaryPreferred";
// Oppure utilizzando le opzioni di connessione nella configurazione del driver
const options = {
  readPreference: "secondaryPreferred"
};

3. Gestione della Sincronizzazione e del Ritardo dei Secondari

Se stai indirizzando le letture ai secondari, le prestazioni di tali letture dipendono interamente dalla velocità con cui i secondari tengono il passo con il primario. Un ritardo di replica elevato significa che i secondari servono dati obsoleti, o se il ritardo è troppo alto, le letture potrebbero fallire o andare in timeout.

Monitoraggio del Ritardo di Replica

Monitora sempre la differenza di optime tra il primario e i secondari. rs.status() mostra lo stato di replica per membro, e strumenti gestiti come MongoDB Atlas, Cloud Manager o Ops Manager possono avvisare in caso di ritardo.

rs.status().members.map(m => ({
  name: m.name,
  stateStr: m.stateStr,
  optimeDate: m.optimeDate
}))

Impatto del Write Concern sulle Prestazioni dei Secondari

Sebbene questo articolo si concentri sulle letture, impostazioni elevate di write concern possono influenzare indirettamente le prestazioni di lettura rallentando il primario, il che a sua volta fa sì che i secondari restino ulteriormente indietro.

Ad esempio, richiedere w: "majority" significa che il client non riceve conferma finché la scrittura non ha raggiunto la maggioranza dei membri votanti che contengono dati. Se i secondari sono lenti a causa di pressione su disco o rete, la latenza di scrittura dell'applicazione può aumentare, e quegli stessi secondari sovraccarichi potrebbero anche servire letture lente.

Migliore Pratica per il Write Concern (Ottimizzazione Indiretta della Lettura): Non abbassare il write concern solo per rendere le letture più veloci. Scegli il write concern in base ai requisiti di durabilità, poi correggi la causa del ritardo: dischi lenti, secondari sovraccarichi, oplog sottodimensionato, problemi di rete o query in competizione con la replica.

4. Indicizzazione e Ottimizzazione delle Query

Nessuna impostazione di configurazione può superare una query mal scritta. Il principio fondamentale per letture veloci rimane una solida indicizzazione.

Considerazioni Chiave sull'Indicizzazione

1. Query Coperte: Progetta query che possono essere completamente soddisfatte da un indice senza recuperare documenti dal disco. Queste sono le letture più veloci possibili.
2. Allineamento degli Indici: Assicurati che gli indici corrispondano ai campi utilizzati nelle clausole find(), sort() e projection().
3. Evita Scansioni di Collezione: Verifica sempre nel profiler delle query che le operazioni di lettura utilizzino indici (IXSCAN) piuttosto che eseguire scansioni complete della collezione (COLLSCAN).

Regolazione dei Timeout delle Query

Se un'applicazione sta colpendo un secondario con un ritardo elevato, la query potrebbe andare in timeout. Configura timeout ragionevoli nella tua applicazione per gestire correttamente il ritardo temporaneo, magari ripiegando sul primario o riprovando più tardi, piuttosto che rimanere in attesa indefinitamente.

Riepilogo dei Passaggi per l'Ottimizzazione della Lettura

Per ottenere prestazioni di lettura ottimali nel tuo replica set MongoDB, segui questi passaggi attuabili:

1. Identifica i Tipi di Lettura: Classifica le letture in quelle che necessitano di dati freschi dal primario e quelle che possono tollerare una consistenza eventuale dai secondari.
2. Configura la Preferenza di Lettura: Imposta la stringa di connessione o le opzioni di sessione per utilizzare secondaryPreferred o nearest per la maggior parte del traffico dell'applicazione.
3. Monitora il Ritardo: Monitora continuamente il ritardo di replica da rs.status(), metriche del driver o dalla tua piattaforma di monitoraggio. Se il ritardo è costantemente elevato, indaga su hardware dei secondari o problemi di rete.
4. Rivedi i Write Concern: Assicurati che i write concern non stiano rallentando indebitamente il primario, il che priva i secondari di dati freschi.
5. Indicizza a Fondo: Verifica che tutti i percorsi di lettura eseguiti frequentemente utilizzino indici efficienti.

Il ridimensionamento delle letture del replica set funziona meglio quando sei onesto riguardo all'obsolescenza. Invia le letture critiche per l'utente al primario quando devono essere aggiornate, utilizza i secondari per analisi o dashboard che possono essere in ritardo, e continua a misurare i piani di query e la salute della replica man mano che il traffico cambia.