Come configurare il driver MongoDB Java MongoOptions per l'uso in produzione?

Aggiornato a 2.9 :

• AutoConnectRetry significa semplicemente che il driver tenterà automaticamente di riconnettersi ai server dopo disconnessioni impreviste. Negli ambienti di produzione di solito vuoi che questo sia impostato su true.

• connectionsPerHost sono la quantità di connessioni fisiche che una singola istanza Mongo (è singleton quindi di solito ne hai una per applicazione) può stabilire a un processo mongod/mongos. Al momento della scrittura, il driver java stabilirà questa quantità di connessioni alla fine anche se il throughput effettivo della query è basso (in parole povere vedrai la statistica "conn" in mongostat aumentare fino a raggiungere questo numero per server app).

  Non è necessario impostarlo su un valore superiore a 100 nella maggior parte dei casi, ma questa impostazione è una di quelle cose "prova e vedi". Tieni presente che dovrai assicurarti di impostarlo sufficientemente basso in modo che la quantità totale di connessioni al tuo server non superi

  db.serverStatus().connections.available

  In produzione attualmente abbiamo questo a 40.

• connectTimeout . Poiché il nome suggerisce il numero di millisecondi, il driver attenderà prima che un tentativo di connessione venga interrotto. Imposta il timeout su qualcosa di lungo (15-30 secondi) a meno che non ci sia una possibilità realistica e prevista che questo ostacoli tentativi di connessione altrimenti riusciti. Normalmente, se un tentativo di connessione richiede più di un paio di secondi, la tua infrastruttura di rete non è in grado di offrire un throughput elevato.

• maxWaitTime . Numero di ms in cui un thread attenderà che una connessione diventi disponibile nel pool di connessioni e solleva un'eccezione se ciò non avviene in tempo. Mantieni predefinito.

• socketTimeout . Valore di timeout del socket standard. Impostare su 60 secondi (60000).

• threadsAllowedToBlockForConnectionMultiplier . Moltiplicatore per connectionPerHost che indica il numero di thread che possono attendere che le connessioni diventino disponibili se il pool è attualmente esaurito. Questa è l'impostazione che causerà l'eccezione "com.mongodb.DBPortPool$SemaphoresOut:Out of semaphores to get db connection". Genera questa eccezione una volta che questa coda di thread supera il valore di threadsAllowedToBlockForConnectionMultiplier. Ad esempio, se connectionPerHost è 10 e questo valore è 5, è possibile bloccare fino a 50 thread prima che venga generata l'eccezione sopra menzionata.

  Se si prevedono grandi picchi di throughput che potrebbero causare code di grandi dimensioni, aumentare temporaneamente questo valore. Al momento lo abbiamo a 1500 esattamente per questo motivo. Se il carico della tua query supera costantemente il server, dovresti semplicemente migliorare la tua situazione hardware/scalabilità di conseguenza.

• leggiPreferenza . (AGGIORNATO, 2.8+) Utilizzato per determinare la preferenza di lettura predefinita e sostituisce "slaveOk". Imposta una ReadPreference tramite uno dei metodi class factory. Una descrizione completa delle impostazioni più comuni è disponibile alla fine di questo post

• con . (AGGIORNATO, 2.6+) Questo valore determina la "sicurezza" della scrittura. Quando questo valore è -1, la scrittura non riporterà alcun errore indipendentemente dagli errori di rete o di database. WriteConcern.NONE è il WriteConcern predefinito appropriato per questo. Se w è 0, gli errori di rete renderanno la scrittura fallita ma gli errori mongo no. Questo è in genere indicato come scritture "fire and forget" e dovrebbe essere utilizzato quando le prestazioni sono più importanti della coerenza e della durata. Utilizzare WriteConcern.NORMAL per questa modalità.

  Se si imposta w su 1 o superiore, la scrittura è considerata sicura. Le scritture sicure eseguono la scrittura e la seguono da una richiesta al server per assicurarsi che la scrittura sia riuscita o recuperare un valore di errore in caso contrario (in altre parole, invia un comando getLastError() dopo la scrittura). Si noti che fino al completamento di questo comando getLastError() la connessione è riservata. Come risultato di ciò e del comando aggiuntivo, il throughput sarà significativamente inferiore alle scritture con w <=0. Con un valore w di esattamente 1 MongoDB garantisce che la scrittura sia riuscita (o verificabilmente fallita) sull'istanza a cui hai inviato la scrittura.

  Nel caso di set di repliche puoi usare valori più alti per w che dicono a MongoDB di inviare la scrittura ad almeno "w" membri del set di repliche prima di restituire (o più precisamente, attendere la replica della tua scrittura ai membri "w" ). Puoi anche impostare w sulla stringa "majority" che dice a MongoDB di eseguire la scrittura sulla maggior parte dei membri del set di repliche (WriteConcern.MAJORITY). In genere dovresti impostarlo su 1 a meno che non siano necessarie prestazioni grezze (-1 o 0) o scritture replicate (>1). I valori superiori a 1 hanno un notevole impatto sulla velocità effettiva di scrittura.

• sincronizzazione . Opzione di durabilità che forza mongo a scaricarsi su disco dopo ogni scrittura quando abilitata. Non ho mai avuto problemi di durabilità relativi a un backlog di scrittura, quindi abbiamo questo valore su false (impostazione predefinita) in produzione.

• j *(NUOVO 2.7+) *. Booleano che, se impostato su true, costringe MongoDB ad attendere un commit del gruppo di journaling riuscito prima di tornare. Se hai abilitato il journaling, puoi abilitarlo per una maggiore durata. Fare riferimento a http://www.mongodb.org/display/DOCS/Journaling per vedere cosa ti dà il journaling (e quindi perché potresti voler abilitare questo flag).

LeggiPreferenza La classe ReadPreference consente di configurare a quali istanze mongod vengono instradate le query se si lavora con i set di repliche. Sono disponibili le seguenti opzioni:

• ReadPreference.primary() :tutte le letture vanno solo al membro principale del ripristino. Utilizzare questa opzione se si richiede che tutte le query restituiscano dati coerenti (scritti più di recente). Questa è l'impostazione predefinita.

• ReadPreference.primaryPreferred() :tutte le letture vanno al membro primario repset, se possibile, ma possono interrogare i membri secondari se il nodo primario non è disponibile. In quanto tale, se il primario diventa non disponibile, le letture alla fine diventano coerenti, ma solo se il primario non è disponibile.

• ReadPreference.secondary() :tutte le letture vanno ai membri repset secondari e il membro principale viene utilizzato solo per le scritture. Usalo solo se riesci a convivere con letture alla fine coerenti. È possibile utilizzare ulteriori membri del repset per aumentare le prestazioni di lettura, sebbene vi siano limiti alla quantità di membri (votanti) che può avere un repset.

• ReadPreference.secondaryPreferred() :tutte le letture vanno ai membri del repset secondario se qualcuno di essi è disponibile. Il membro principale viene utilizzato esclusivamente per le scritture a meno che tutti i membri secondari non siano disponibili. A parte il fallback al membro primario per le letture, è lo stesso di ReadPreference.secondary().

• ReadPreference.neast() :Le letture vanno al membro repset più vicino disponibile per il client del database. Utilizzare solo se le letture eventualmente coerenti sono accettabili. Il membro più vicino è il membro con la latenza più bassa tra il client e i vari membri del repset. Dal momento che i membri impegnati avranno alla fine latenze più elevate, questo dovrebbe bilancia automaticamente anche il carico di lettura anche se nella mia esperienza secondario (Preferred) sembra funzionare meglio se le latenze dei membri sono relativamente coerenti.

Nota:tutto quanto sopra ha versioni abilitate per i tag dello stesso metodo che restituiscono invece istanze TaggableReadPreference. Una descrizione completa dei tag dei set di repliche può essere trovata qui:Tag dei set di repliche