¿Cómo configurar el controlador MongoDB Java MongoOptions para uso en producción?

Actualizado a 2.9:

• reintento de conexión automática simplemente significa que el controlador intentará automáticamente volver a conectarse a los servidores después de desconexiones inesperadas. En entornos de producción, normalmente desea que este conjunto sea verdadero.

• conexiones por host son la cantidad de conexiones físicas que una sola instancia de Mongo (es singleton, por lo que generalmente tiene una por aplicación) puede establecer para un proceso mongod/mongos. Al momento de escribir, el controlador Java establecerá esta cantidad de conexiones eventualmente, incluso si el rendimiento real de la consulta es bajo (en otras palabras, verá que la estadística de "conexiones" en mongostat aumenta hasta que alcanza este número por servidor de aplicaciones).

  No hay necesidad de configurarlo por encima de 100 en la mayoría de los casos, pero esta configuración es una de esas cosas de "pruébalo y verás". Tenga en cuenta que deberá asegurarse de configurarlo lo suficientemente bajo para que la cantidad total de conexiones a su servidor no exceda

  db.serverStatus().connections.available

  En producción, actualmente tenemos esto a 40.

• tiempo de espera de conexión . Como el nombre sugiere, el número de milisegundos que esperará el controlador antes de cancelar un intento de conexión. Establezca el tiempo de espera en algo largo (15 a 30 segundos) a menos que exista una posibilidad realista y esperada de que esto impida que los intentos de conexión sean exitosos. Normalmente, si un intento de conexión tarda más de un par de segundos, su infraestructura de red no es capaz de un alto rendimiento.

• tiempo de espera máximo . Número de ms que un subproceso esperará a que una conexión esté disponible en el grupo de conexiones y generará una excepción si esto no sucede a tiempo. Mantener predeterminado.

• tiempo de espera de socket . Valor de tiempo de espera de socket estándar. Establecer en 60 segundos (60000).

• threadsAllowedToBlockForConnectionMultiplier . Multiplicador para connectionsPerHost que indica la cantidad de subprocesos que pueden esperar a que las conexiones estén disponibles si el grupo está actualmente agotado. Esta es la configuración que causará la excepción "com.mongodb.DBPortPool$SemaphoresOut:Out of semaphores to get db connection". Lanzará esta excepción una vez que esta cola de subprocesos exceda el valor de threadsAllowedToBlockForConnectionMultiplier. Por ejemplo, si connectionsPerHost es 10 y este valor es 5, se pueden bloquear hasta 50 subprocesos antes de que se produzca la excepción antes mencionada.

  Si espera grandes picos en el rendimiento que podrían causar grandes colas, aumente temporalmente este valor. Lo tenemos en 1500 en este momento exactamente por esa razón. Si la carga de su consulta supera constantemente al servidor, debe mejorar su situación de hardware/escalado en consecuencia.

• preferencia de lectura . (ACTUALIZADO, 2.8+) Se utiliza para determinar la preferencia de lectura predeterminada y reemplaza a "slaveOk". Configure una ReadPreference a través de uno de los métodos de fábrica de clases. Puede encontrar una descripción completa de las configuraciones más comunes al final de esta publicación

• w . (ACTUALIZADO, 2.6+) Este valor determina la "seguridad" de la escritura. Cuando este valor es -1, la escritura no informará ningún error, independientemente de los errores de la red o de la base de datos. WriteConcern.NONE es el WriteConcern predefinido apropiado para esto. Si w es 0, los errores de red harán que la escritura falle, pero los errores de mongo no. Por lo general, esto se denomina escritura "dispara y olvida" y debe usarse cuando el rendimiento es más importante que la consistencia y la durabilidad. Utilice WriteConcern.NORMAL para este modo.

  Si establece w en 1 o superior, la escritura se considera segura. Las escrituras seguras realizan la escritura y la siguen con una solicitud al servidor para asegurarse de que la escritura se realizó correctamente o recuperar un valor de error si no fue así (en otras palabras, envía un comando getLastError() después de escribir). Tenga en cuenta que hasta que se complete este comando getLastError(), la conexión está reservada. Como resultado de eso y del comando adicional, el rendimiento será significativamente menor que las escrituras con w <=0. Con un valor de w de exactamente 1, MongoDB garantiza que la escritura se realizó correctamente (o falló verificablemente) en la instancia a la que envió la escritura.

  En el caso de los conjuntos de réplicas, puede usar valores más altos para w que le indican a MongoDB que envíe la escritura a al menos "w" miembros del conjunto de réplicas antes de regresar (o más exactamente, espere la replicación de su escritura a los miembros "w" ). También puede establecer w en la cadena "mayoría" que le dice a MongoDB que realice la escritura en la mayoría de los miembros del conjunto de réplicas (WriteConcern.MAJORITY). Por lo general, debe establecer esto en 1 a menos que necesite un rendimiento sin procesar (-1 o 0) o escrituras replicadas (>1). Los valores superiores a 1 tienen un impacto considerable en el rendimiento de escritura.

• fsync . Opción de durabilidad que obliga a Mongo a descargarse en el disco después de cada escritura cuando está habilitada. Nunca he tenido problemas de durabilidad relacionados con una acumulación de escritura, por lo que tenemos esto en falso (el valor predeterminado) en producción.

• j *(NUEVO 2.7+) *. Booleano que, cuando se establece en verdadero, obliga a MongoDB a esperar una confirmación exitosa del grupo de diario antes de regresar. Si tiene habilitado el registro en diario, puede habilitarlo para mayor durabilidad. Consulte http://www.mongodb.org/display/DOCS/Journaling para ver qué le ofrece el diario (y, por lo tanto, por qué es posible que desee habilitar esta marca).

Preferencia de lectura La clase ReadPreference le permite configurar a qué instancias mongod se enrutan las consultas si está trabajando con conjuntos de réplicas. Las siguientes opciones están disponibles:

• Preferencia de lectura.primary() :Todas las lecturas van solo al miembro principal del repset. Use esto si necesita que todas las consultas devuelvan datos coherentes (los escritos más recientemente). Este es el valor predeterminado.

• ReadPreference.primaryPreferred() :todas las lecturas se dirigen al miembro principal del repset si es posible, pero pueden consultar a los miembros secundarios si el nodo principal no está disponible. Como tal, si el primario deja de estar disponible, las lecturas eventualmente se vuelven consistentes, pero solo si el primario no está disponible.

• Preferencia de lectura.secundaria() :Todas las lecturas van a los miembros secundarios de repset y el miembro principal se usa solo para escrituras. Use esto solo si puede vivir con lecturas eventualmente consistentes. Se pueden usar miembros adicionales del conjunto de representantes para escalar el rendimiento de lectura, aunque hay límites en la cantidad de miembros (con derecho a voto) que puede tener un conjunto de representantes.

• ReadPreference.secundarioPreferido() :Todas las lecturas van a los miembros del conjunto de representantes secundarios si alguno de ellos está disponible. El miembro principal se usa exclusivamente para escrituras a menos que todos los miembros secundarios dejen de estar disponibles. Aparte del respaldo al miembro principal para las lecturas, esto es lo mismo que ReadPreference.secondary().

• Preferencia de lectura.más cercana() :Las lecturas van al miembro de repset más cercano disponible para el cliente de la base de datos. Úselo solo si las lecturas eventualmente consistentes son aceptables. El miembro más cercano es el miembro con la latencia más baja entre el cliente y los distintos miembros del repset. Dado que los miembros ocupados eventualmente tendrán latencias más altas, esto debería también equilibra automáticamente la carga de lectura, aunque en mi experiencia secundaria (Preferido) parece hacerlo mejor si las latencias de los miembros son relativamente consistentes.

Nota:Todos los anteriores tienen versiones habilitadas para etiquetas del mismo método que, en su lugar, devuelven instancias TaggableReadPreference. Puede encontrar una descripción completa de las etiquetas del conjunto de réplicas aquí:Etiquetas del conjunto de réplicas