Wie konfiguriere ich den MongoDB-Java-Treiber MongoOptions für den Produktionseinsatz?

Aktualisiert auf 2.9 :

• autoConnectRetry bedeutet einfach, dass der Treiber nach unerwarteten Verbindungsabbrüchen automatisch versucht, sich wieder mit dem/den Server(n) zu verbinden. In Produktionsumgebungen möchten Sie diese Einstellung normalerweise auf true setzen.

• VerbindungenproHost sind die Anzahl der physischen Verbindungen, die eine einzelne Mongo-Instanz (es ist Singleton, also haben Sie normalerweise eine pro Anwendung) zu einem Mongod/Mongos-Prozess herstellen kann. Zum Zeitpunkt des Schreibens stellt der Java-Treiber diese Anzahl von Verbindungen schließlich her, selbst wenn der tatsächliche Abfragedurchsatz niedrig ist (mit anderen Worten, Sie werden sehen, wie die „conn“-Statistik in Mongostat ansteigt, bis sie diese Zahl pro App-Server erreicht).

  In den meisten Fällen ist es nicht erforderlich, dies höher als 100 einzustellen, aber diese Einstellung ist eine dieser "testen und sehen"-Dinge. Beachten Sie, dass Sie diesen Wert niedrig genug einstellen müssen, damit die Gesamtzahl der Verbindungen zu Ihrem Server

  nicht überschreitet

  db.serverStatus().connections.available

  In der Produktion haben wir dies derzeit bei 40.

• connectTimeout . Wie der Name schon sagt, wie viele Millisekunden der Treiber wartet, bevor ein Verbindungsversuch abgebrochen wird. Setzen Sie das Zeitlimit auf einen langen Wert (15-30 Sekunden), es sei denn, es besteht eine realistische, zu erwartende Chance, dass dies ansonsten erfolgreichen Verbindungsversuchen im Wege steht. Wenn ein Verbindungsversuch länger als ein paar Sekunden dauert, ist Ihre Netzwerkinfrastruktur normalerweise nicht in der Lage, einen hohen Durchsatz zu erzielen.

• maxWaitTime . Anzahl der Millisekunden, die ein Thread darauf wartet, dass eine Verbindung im Verbindungspool verfügbar wird, und eine Ausnahme auslöst, wenn dies nicht rechtzeitig geschieht. Standard beibehalten.

• socketTimeout . Standard-Socket-Timeout-Wert. Auf 60 Sekunden (60000) einstellen.

• threadsAllowedToBlockForConnectionMultiplier . Multiplikator für connectionsPerHost, der die Anzahl der Threads angibt, die warten dürfen, bis Verbindungen verfügbar werden, wenn der Pool derzeit erschöpft ist. Dies ist die Einstellung, die die Ausnahme „com.mongodb.DBPortPool$SemaphoresOut:Out of semaphores to get db connection“ verursacht. Diese Ausnahme wird ausgelöst, sobald diese Threadwarteschlange den ThreadsAllowedToBlockForConnectionMultiplier-Wert überschreitet. Wenn beispielsweise connectionsPerHost 10 ist und dieser Wert 5 ist, können bis zu 50 Threads blockieren, bevor die oben erwähnte Ausnahme ausgelöst wird.

  Wenn Sie große Durchsatzspitzen erwarten, die zu großen Warteschlangen führen könnten, erhöhen Sie diesen Wert vorübergehend. Genau aus diesem Grund haben wir ihn im Moment bei 1500. Wenn Ihre Abfragelast die des Servers ständig übersteigt, sollten Sie einfach Ihre Hardware-/Skalierungssituation entsprechend verbessern.

• readPreference . (AKTUALISIERT, 2.8+) Wird verwendet, um die standardmäßige Lesepräferenz zu bestimmen und ersetzt "slaveOk". Richten Sie eine ReadPreference über eine der Klassen-Factory-Methoden ein. Eine vollständige Beschreibung der gängigsten Einstellungen finden Sie am Ende dieses Beitrags

• w . (AKTUALISIERT, 2.6+) Dieser Wert bestimmt die "Sicherheit" des Schreibens. Wenn dieser Wert -1 ist, meldet der Schreibvorgang keine Fehler, unabhängig von Netzwerk- oder Datenbankfehlern. WriteConcern.NONE ist dafür das passende vordefinierte WriteConcern. Wenn w 0 ist, führen Netzwerkfehler dazu, dass der Schreibvorgang fehlschlägt, Mongo-Fehler jedoch nicht. Dies wird in der Regel als „Fire and Forget“-Schreibvorgänge bezeichnet und sollte verwendet werden, wenn Leistung wichtiger ist als Konsistenz und Dauerhaftigkeit. Verwenden Sie für diesen Modus WriteConcern.NORMAL.

  Wenn Sie w auf 1 oder höher setzen, gilt der Schreibvorgang als sicher. Sichere Schreibvorgänge führen den Schreibvorgang aus und folgen ihm durch eine Anfrage an den Server, um sicherzustellen, dass der Schreibvorgang erfolgreich war, oder rufen einen Fehlerwert ab, wenn dies nicht der Fall war (mit anderen Worten, er sendet nach dem Schreiben einen getLastError()-Befehl). Beachten Sie, dass die Verbindung bis zum Abschluss dieses getLastError()-Befehls reserviert ist. Infolgedessen und des zusätzlichen Befehls ist der Durchsatz deutlich niedriger als bei Schreibvorgängen mit w <=0. Mit einem w-Wert von genau 1 garantiert MongoDB, dass der Schreibvorgang auf der Instanz, an die Sie den Schreibvorgang gesendet haben, erfolgreich war (oder nachweislich fehlgeschlagen ist).

  Im Fall von Replikatsätzen können Sie höhere Werte für w verwenden, die MongoDB anweisen, den Schreibvorgang an mindestens „w“ Mitglieder des Replikatsatzes zu senden, bevor er zurückkehrt (oder genauer gesagt, warten Sie auf die Replikation Ihres Schreibvorgangs an „w“ Mitglieder ). Sie können w auch auf die Zeichenfolge „majority“ setzen, die MongoDB anweist, den Schreibvorgang für die Mehrheit der Mitglieder des Replikatsatzes durchzuführen (WriteConcern.MAJORITY). Normalerweise sollten Sie dies auf 1 setzen, es sei denn, Sie benötigen reine Leistung (-1 oder 0) oder replizierte Schreibvorgänge (>1). Werte über 1 wirken sich erheblich auf den Schreibdurchsatz aus.

• fsync . Haltbarkeitsoption, die Mongo dazu zwingt, nach jedem Schreibvorgang auf die Festplatte zu schreiben, wenn sie aktiviert ist. Ich hatte noch nie Haltbarkeitsprobleme im Zusammenhang mit einem Schreibrückstand, also haben wir dies in der Produktion auf false (Standardeinstellung).

• j *(NEU 2.7+) *. Boolean, der, wenn er auf „true“ gesetzt ist, MongoDB dazu zwingt, vor der Rückkehr auf einen erfolgreichen Journaling-Gruppen-Commit zu warten. Wenn Sie Journaling aktiviert haben, können Sie dies für zusätzliche Haltbarkeit aktivieren. Unter http://www.mongodb.org/display/DOCS/Journaling erfahren Sie, was Ihnen Journaling bringt (und warum Sie dieses Flag möglicherweise aktivieren sollten).

Lesepräferenz Mit der ReadPreference-Klasse können Sie konfigurieren, an welche Mongod-Instanzen Abfragen weitergeleitet werden, wenn Sie mit Replikatsätzen arbeiten. Die folgenden Optionen sind verfügbar:

• ReadPreference.primary() :Alle Lesevorgänge gehen nur an das primäre Mitglied des Repsets. Verwenden Sie dies, wenn alle Abfragen konsistente (die zuletzt geschriebenen) Daten zurückgeben sollen. Dies ist die Standardeinstellung.

• ReadPreference.primaryPreferred() :Alle Lesevorgänge gehen nach Möglichkeit an das primäre Mitglied des Repsets, können aber sekundäre Mitglieder abfragen, wenn der primäre Knoten nicht verfügbar ist. Wenn also der primäre nicht verfügbar wird, werden die Lesevorgänge schließlich konsistent, aber nur, wenn der primäre nicht verfügbar ist.

• ReadPreference.secondary() :Alle Lesevorgänge gehen an sekundäre Repset-Mitglieder und das primäre Mitglied wird nur für Schreibvorgänge verwendet. Verwenden Sie dies nur, wenn Sie mit eventuell konsistenten Lesevorgängen leben können. Zusätzliche Repset-Mitglieder können verwendet werden, um die Leseleistung zu erhöhen, obwohl die Anzahl der (stimmberechtigten) Mitglieder, die ein Repset haben kann, begrenzt ist.

• ReadPreference.secondaryPreferred() :Alle Reads gehen an sekundäre Repset-Mitglieder, falls welche verfügbar sind. Das primäre Mitglied wird ausschließlich für Schreibvorgänge verwendet, es sei denn, alle sekundären Mitglieder sind nicht mehr verfügbar. Abgesehen vom Fallback auf das primäre Mitglied für Lesevorgänge ist dies dasselbe wie ReadPreference.secondary().

• ReadPreference.nearest() :Lesevorgänge werden an das nächste für den Datenbankclient verfügbare Repset-Mitglied weitergeleitet. Nur verwenden, wenn eventuell konsistente Lesevorgänge akzeptabel sind. Das nächste Mitglied ist das Mitglied mit der niedrigsten Latenzzeit zwischen dem Client und den verschiedenen Repset-Mitgliedern. Da vielbeschäftigte Mitglieder letztendlich höhere Latenzen haben werden, sollte dies der Fall sein gleicht auch automatisch die Leselast aus, obwohl meiner Erfahrung nach sekundäre (bevorzugt) dies besser zu tun scheint, wenn die Latenzen der Mitglieder relativ konstant sind.

Hinweis:Alle oben genannten haben Tag-aktivierte Versionen derselben Methode, die stattdessen TaggableReadPreference-Instanzen zurückgeben. Eine vollständige Beschreibung der Replikat-Set-Tags finden Sie hier:Replikat-Set-Tags