En esta página podrás encontrar preguntas frecuentes y sus correspondientes respuestas.
Tip
Si no encuentras una respuesta a tu pregunta en esta página, consulta la Página de problemas y ayuda para obtener información sobre cómo informar de problemas.
¿Por qué tengo problemas al conectarme a una instancia de MongoDB?
Si tienes problemas para conectar con una implementación de MongoDB, consulta la Guía de solución de problemas de conexión para soluciones posibles.
¿En qué se diferencia el controlador de Kotlin de KMongo?
El controlador de Kotlin es el controlador oficial de MongoDB para Kotlin. Está desarrollado por el equipo de MongoDB y proporciona una API nativa para que las aplicaciones Kotlin se conecten a MongoDB y trabajen con datos. Se implementa encapsulando el Controlador Java de MongoDB.
KMongo Es una biblioteca popular, desarrollada por la comunidad, para trabajar con MongoDB desde aplicaciones Kotlin. Es un contenedor del controlador de Java, creado antes de la creación del controlador oficial de Kotlin para satisfacer las necesidades de la comunidad Kotlin.
Importante
A partir de julio de 2023, KMongo ha sido marcado como obsoleto.
El controlador Kotlin se desarrolló en colaboración con el creador de KMongo, Julien Buret, para ofrecer a los usuarios un controlador con soporte oficial.
El controlador oficial de Kotlin y KMongo tienen APIs generalmente similares. Las similitudes notables entre el controlador de Kotlin y KMongo incluyen:
Soporte para operaciones síncronas y basadas en corrutinas
Admite el uso de clases de datos para representar documentos MongoDB
Compatibilidad con la serialización de KotlinX
Compatibilidad con la API CRUD de MongoDB y la API de agregación
Aunque el controlador oficial de Kotlin y KMongo son similares, existen algunas diferencias clave:
El controlador oficial no tiene soporte integrado para reactor, rxjava,2 Jackson o GSON.
El driver oficial no admite comandos de shell de MongoDB.
Para obtener información más detallada, consulte Migrar desde KMongo.
¿Cómo funciona el agrupamiento de conexiones en el controlador de Kotlin?
Cada MongoClient La instancia tiene un pool de conexiones integrado para cada servidor en su topología de MongoDB. Los pools de conexiones abren sockets on-demand para soportar operaciones concurrentes de MongoDB en su aplicación multihilo.
El tamaño máximo de cada grupo de conexiones se establece mediante la opción maxPoolSize, cuyo valor predeterminado es 100. Si el número de conexiones en uso a un servidor alcanza maxPoolSize, la siguiente solicitud a ese servidor esperará hasta que haya una conexión disponible.
Cada instancia de MongoClient abre dos sockets adicionales por servidor en tu topología de MongoDB para la supervisión del estado del servidor.
Por ejemplo, un cliente conectado a un set de réplicas de 3 nodos abre 6 sockets de supervisión. También abre tantos sockets como sea necesario para admitir los hilos de una aplicación en cada servidor, hasta el valor de maxPoolSize. Si maxPoolSize es 100 y la aplicación utiliza únicamente la opción primario (por defecto), solo el pool de conexiones primario crecerá y puede haber, como máximo, 106 conexiones en total. Si la aplicación utiliza una preferencia de lectura para consultar los nodos secundarios, sus pools también crecen y puede haber un total de 306 conexiones.
Además, los pools de conexiones tienen un límite de tasa, de modo que cada pool de conexiones solo puede crear, como máximo, el valor de maxConnecting conexiones en paralelo en cualquier momento. Cualquier hilo adicional deja de esperar en los siguientes casos:
Uno de los subprocesos existentes termina de crear una conexión, o una conexión existente se devuelve al grupo.
La capacidad del controlador para reutilizar conexiones existentes mejora debido a los límites de velocidad en la creación de conexiones.
Puedes establecer el número mínimo de conexiones concurrentes a cada servidor con la opción minPoolSize, que por defecto es 0. El pool de conexiones se inicializará con este número de sockets. Si se cierran sockets debido a errores de red y el número total de sockets (tanto en uso como inactivos) cae por debajo del mínimo, se abrirán más sockets hasta alcanzar el mínimo.
Puede establecer la cantidad máxima de milisegundos que una conexión puede permanecer inactiva en el grupo antes de ser eliminada y reemplazada con la opción maxIdleTimeMS, cuyo valor predeterminado es 0 (sin límite).
La siguiente configuración por defecto para un MongoClient funciona para la mayoría de las aplicaciones:
val client = MongoClient("<connection string>")
Cree un cliente para cada proceso y reutilícelo para todas las operaciones. Es un error común crear un cliente para cada solicitud, lo cual resulta muy ineficiente.
Para soportar un alto número de operaciones MongoDB concurrentes dentro de un proceso, puede aumentar maxPoolSize. Una vez que el pool alcanza su tamaño máximo, los hilos adicionales esperan a que los sockets estén disponibles.
El controlador no limita la cantidad de hilos que pueden esperar a que estén disponibles los sockets, y es responsabilidad de la aplicación limitar el tamaño de su grupo para limitar la cola durante un pico de carga. Los hilos esperan durante el tiempo especificado en la opción waitQueueTimeoutMS, que por defecto es 120000 (120 segundos).
Un hilo que espera más tiempo del definido por waitQueueTimeoutMS para un socket genera un error de conexión. Utiliza esta opción si es más importante limitar la duración de las operaciones durante un pico de carga que completar cada operación.
Cuando cualquier hilo llama a MongoClient.close(), el controlador cierra todos los sockets inactivos y cierra todos los sockets que están en uso a medida que se devuelven al grupo.
Para obtener más información sobre cómo conectarse a MongoDB, consulte la Guía de conexión.