En esta página podrás encontrar preguntas frecuentes y sus correspondientes respuestas.
Tip
Si no puede encontrar una respuesta a su pregunta en esta página, consulte la Página de problemasy ayuda para obtener información sobre cómo informar problemas.
¿Por qué tengo problemas al conectarme a una instancia de MongoDB?
Si tiene problemas para conectarse a una implementación de MongoDB, consulte la Guía de solución de problemas de conexión para obtener posibles soluciones.
¿En qué se diferencia el controlador Kotlin de KMongo?
El controlador Kotlin es el controlador oficial de MongoDB para Kotlin. Desarrollado por el equipo de MongoDB, proporciona una API nativa para que las aplicaciones Kotlin se conecten a MongoDB y trabajen con datos. Se implementa encapsulando 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 del 2023 de julio, 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. Entre las similitudes más notables se 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 controlador 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 Kotlin?
Cada MongoClient Cada instancia cuenta con un grupo de conexiones integrado para cada servidor de su topología MongoDB. Los grupos de conexiones abren sockets a demanda para admitir operaciones simultáneas 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 MongoClient abre dos sockets adicionales por servidor en su topología MongoDB para monitorear el estado del servidor.
Por ejemplo, un cliente conectado a un conjunto 3 6 de réplicas de nodos abre sockets de monitorización. También abre tantos sockets como sean necesarios para soportar los subprocesos de una aplicación en cada servidor, hasta un valor maxPoolSize de. Si maxPoolSize es 100 y la aplicación solo usa el servidor principal (predeterminado), solo el grupo de conexiones principal crece y puede haber 106 un máximo de conexiones. Si la aplicación usa una preferencia de lectura para consultar los nodos secundarios, sus grupos también crecen y puede haber un 306 total de conexiones.
Además, los grupos de conexiones tienen una velocidad limitada, de modo que cada uno solo puede crear, como máximo, maxConnecting conexiones en paralelo en cualquier momento. Cualquier subproceso 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.
Puede establecer el número mínimo de conexiones simultáneas a cada servidor con la opción minPoolSize, cuyo valor predeterminado es 0. El grupo de conexiones se inicializará con este número de sockets. Si los sockets se cierran debido a errores de red, lo que provoca que el número total de sockets (tanto en uso como inactivos) caiga por debajo del mínimo, se abrirán más sockets hasta alcanzarlo.
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 predeterminada 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 subproceso que espera más tiempo del definido por waitQueueTimeoutMS para un socket genera un error de conexión. Use 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.