Comment configurer le pilote Java MongoDB MongoOptions pour une utilisation en production ?

Mise à jour en 2.9 :

• autoConnectRetry signifie simplement que le pilote tentera automatiquement de se reconnecter au(x) serveur(s) après des déconnexions inattendues. Dans les environnements de production, vous souhaitez généralement que ce paramètre soit défini sur true.

• connexions par hôte sont la quantité de connexions physiques qu'une seule instance de Mongo (c'est un singleton, vous en avez donc généralement une par application) peut établir avec un processus mongod/mongos. Au moment de la rédaction, le pilote Java établira éventuellement ce nombre de connexions, même si le débit réel de la requête est faible (dans l'ordre, vous verrez la statistique "conn" dans mongostat augmenter jusqu'à ce qu'elle atteigne ce nombre par serveur d'application).

  Il n'est pas nécessaire de le définir au-dessus de 100 dans la plupart des cas, mais ce paramètre fait partie de ces choses "testez-le et voyez". Notez que vous devrez vous assurer que ce paramètre est suffisamment bas pour que le nombre total de connexions à votre serveur ne dépasse pas

  db.serverStatus().connections.available

  En production, nous en avons actuellement à 40.

• connectTimeout . Comme son nom l'indique, le nombre de millisecondes pendant lesquelles le pilote attendra avant qu'une tentative de connexion ne soit interrompue. Réglez le délai d'attente sur quelque chose de long (15 à 30 secondes) à moins qu'il n'y ait une chance réaliste et attendue que cela entrave les tentatives de connexion autrement réussies. Normalement, si une tentative de connexion prend plus de quelques secondes, votre infrastructure réseau n'est pas capable d'offrir un débit élevé.

• maxWaitTime . Nombre de ms pendant lequel un thread attendra qu'une connexion soit disponible sur le pool de connexions et lève une exception si cela ne se produit pas à temps. Conserver la valeur par défaut.

• socketTimeout . Valeur standard du délai d'expiration du socket. Défini sur 60 secondes (60 000).

• threadsAllowedToBlockForConnectionMultiplier . Multiplicateur pour connectionsPerHost qui indique le nombre de threads autorisés à attendre que les connexions deviennent disponibles si le pool est actuellement épuisé. C'est le paramètre qui provoquera l'exception "com.mongodb.DBPortPool$SemaphoresOut :il n'y a plus de sémaphores pour obtenir la connexion à la base de données". Il lèvera cette exception une fois que cette file d'attente de threads dépassera la valeur threadsAllowedToBlockForConnectionMultiplier. Par exemple, si connectionsPerHost est 10 et que cette valeur est 5, jusqu'à 50 threads peuvent se bloquer avant que l'exception susmentionnée ne soit levée.

  Si vous vous attendez à de gros pics de débit pouvant entraîner de grandes files d'attente, augmentez temporairement cette valeur. Nous l'avons à 1500 pour le moment exactement pour cette raison. Si la charge de votre requête dépasse systématiquement celle du serveur, vous devez simplement améliorer votre situation matérielle/de mise à l'échelle en conséquence.

• readPreference . (MISE À JOUR, 2.8+) Utilisé pour déterminer la préférence de lecture par défaut et remplace "slaveOk". Configurez une ReadPreference via l'une des méthodes de fabrique de classe. Une description complète des paramètres les plus courants se trouve à la fin de cet article

• w . (MISE À JOUR, 2.6+) Cette valeur détermine la "sécurité" de l'écriture. Lorsque cette valeur est -1, l'écriture ne signalera aucune erreur, quelles que soient les erreurs de réseau ou de base de données. WriteConcern.NONE est le WriteConcern prédéfini approprié pour cela. Si w vaut 0, les erreurs réseau feront échouer l'écriture, mais pas les erreurs mongo. Ceci est généralement appelé écriture "fire and forget" et doit être utilisé lorsque les performances sont plus importantes que la cohérence et la durabilité. Utilisez WriteConcern.NORMAL pour ce mode.

  Si vous définissez w sur 1 ou plus, l'écriture est considérée comme sûre. Les écritures sécurisées effectuent l'écriture et la suivent par une requête au serveur pour s'assurer que l'écriture a réussi ou pour récupérer une valeur d'erreur si ce n'est pas le cas (en d'autres termes, elle envoie une commande getLastError() après l'écriture). Notez que tant que cette commande getLastError() n'est pas terminée, la connexion est réservée. En conséquence de cela et de la commande supplémentaire, le débit sera nettement inférieur aux écritures avec w <=0. Avec une valeur w d'exactement 1, MongoDB garantit que l'écriture a réussi (ou a échoué de manière vérifiable) sur l'instance à laquelle vous avez envoyé l'écriture.

  Dans le cas des jeux de répliques, vous pouvez utiliser des valeurs plus élevées pour w qui indiquent à MongoDB d'envoyer l'écriture à au moins "w" membres du jeu de répliques avant de revenir (ou plus précisément, attendez la réplication de votre écriture aux membres "w" ). Vous pouvez également définir w sur la chaîne "majority" qui indique à MongoDB d'effectuer l'écriture sur la majorité des membres du jeu de réplicas (WriteConcern.MAJORITY). En règle générale, vous devez le définir sur 1, sauf si vous avez besoin de performances brutes (-1 ou 0) ou d'écritures répliquées (> 1). Les valeurs supérieures à 1 ont un impact considérable sur le débit en écriture.

• fsync . Option de durabilité qui force mongo à vider sur le disque après chaque écriture lorsqu'elle est activée. Je n'ai jamais eu de problèmes de durabilité liés à un backlog d'écriture, nous avons donc ceci sur false (la valeur par défaut) en production.

• j *(NOUVEAU 2.7+) *. Boolean qui, lorsqu'il est défini sur true, force MongoDB à attendre un commit de groupe de journalisation réussi avant de revenir. Si vous avez activé la journalisation, vous pouvez l'activer pour une durabilité supplémentaire. Reportez-vous à http://www.mongodb.org/display/DOCS/Journaling pour voir ce que la journalisation vous apporte (et donc pourquoi vous voudrez peut-être activer cet indicateur).

ReadPreference La classe ReadPreference vous permet de configurer vers quelles instances mongod les requêtes sont acheminées si vous travaillez avec des jeux de répliques. Les options suivantes sont disponibles :

• ReadPreference.primary() :Toutes les lectures vont au membre principal du repset uniquement. Utilisez ceci si vous avez besoin que toutes les requêtes renvoient des données cohérentes (les plus récemment écrites). C'est la valeur par défaut.

• ReadPreference.primaryPreferred() :Toutes les lectures vont au membre principal du repset si possible, mais peuvent interroger les membres secondaires si le nœud principal n'est pas disponible. Ainsi, si le primaire devient indisponible, les lectures deviennent finalement cohérentes, mais uniquement si le primaire est indisponible.

• ReadPreference.secondaire() :Toutes les lectures vont aux membres secondaires du repset et le membre principal est utilisé uniquement pour les écritures. Utilisez-le uniquement si vous pouvez vivre avec des lectures cohérentes à terme. Des membres de repset supplémentaires peuvent être utilisés pour augmenter les performances de lecture, bien qu'il existe des limites au nombre de membres (votants) qu'un repset peut avoir.

• ReadPreference.secondairePreferred() :Toutes les lectures vont aux membres du repset secondaire si l'un d'entre eux est disponible. Le membre principal est utilisé exclusivement pour les écritures, sauf si tous les membres secondaires deviennent indisponibles. Hormis le retour au membre principal pour les lectures, c'est la même chose que ReadPreference.secondaire().

• ReadPreference.nearest() :les lectures vont au membre du repset le plus proche disponible pour le client de la base de données. À n'utiliser que si les lectures cohérentes à terme sont acceptables. Le membre le plus proche est le membre avec la latence la plus faible entre le client et les différents membres du repset. Étant donné que les membres occupés auront éventuellement des latences plus élevées, cela devrait équilibre également automatiquement la charge de lecture bien que, d'après mon expérience, le secondaire (préféré) semble le faire mieux si les latences des membres sont relativement cohérentes.

Remarque :Tous les éléments ci-dessus ont des versions de la même méthode activées par balise qui renvoient des instances TaggableReadPreference à la place. Une description complète des balises d'ensemble de répliques peut être trouvée ici :Balises d'ensemble de répliques