Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

Configurar las operaciones CRUD

En esta guía, puedes aprender cómo configurar las opciones de nivel de confirmación de escritura (write concern), nivel de consistencia de lectura y preferencia de lectura para modificar la forma en que el driver de Kotlin realiza las operaciones de lectura y escritura en los conjuntos de réplicas.

Puedes establecer las opciones de nivel de confirmación de escritura (write concern), nivel de consistencia de lectura y preferencia de lectura en los siguientes niveles:

  • Cliente, que establece el por defecto para todas las ejecuciones de operaciones, a menos que se anule

  • transacción

  • Database

  • Colección

Esta lista también indica el orden creciente de prioridad de las configuraciones de opciones. Por ejemplo, si se establece un nivel de consistencia de lectura para una transacción, se anularán las configuraciones de nivel de consistencia de lectura heredadas del cliente.

Las opciones de nivel de confirmación de escritura (write concern), nivel de consistencia de lectura y preferencia de lectura te permiten personalizar la coherencia causal y la disponibilidad de los datos en tus conjuntos de réplicas. Para ver una lista completa de estas opciones, consulte las siguientes guías en el manual del servidor MongoDB:

  • preferencia de lectura

  • readConcern

  • Nivel de confirmación de escritura

Se puede controlar cómo el driver enruta las operaciones de lectura entre los miembros del set de réplicas estableciendo una preferencia de lectura. También puedes controlar cómo el driver espera el reconocimiento de las operaciones de lectura y nivel de confirmación de escritura (write concern) en un set de réplicas configurando los concerns de lectura y nivel de confirmación de escritura (write concern).

Las siguientes secciones muestran cómo configurar estos parámetros de lectura y guardado en varios niveles.

Este ejemplo muestra cómo establecer la preferencia de lectura, el nivel de consistencia de lectura y el nivel de confirmación de escritura (write concern) de un MongoClient instancia pasando una instancia MongoClientSettings al método MongoClient.create(). El código configura los siguientes ajustes:

  • secondary preferencia de lectura: las operaciones de lectura recuperan datos de miembros secundarios del set de réplicas.

  • LOCAL Preocupación de lectura: las operaciones de lectura devuelven los datos más recientes de la instancia sin garantizar que los datos se hayan escrito en la mayoría de los miembros del conjunto de réplicas.

  • W2 nivel de confirmación de escritura (write concern): El primario del set de réplicas y un secundario deben reconocer la operación de grabación.

val settings = MongoClientSettings.builder()
.applyConnectionString(ConnectionString("mongodb://localhost:27017/"))
.readPreference(ReadPreference.secondary())
.readConcern(ReadConcern.LOCAL)
.writeConcern(WriteConcern.W2)
.build()
val mongoClient = MongoClient.create(settings)

Como alternativa, puede especificar los ajustes de lectura y escritura en el URI de conexión, que se pasa como un parámetro al método MongoClient.create():

val uri = "mongodb://localhost:27017/?readPreference=secondary&w=2&readConcernLevel=local"
val uriClient = MongoClient.create(uri)

Este ejemplo muestra cómo establecer la preferencia de lectura, el nivel de consistencia de lectura y el nivel de confirmación de escritura (write concern) de una transacción pasando una instancia de TransactionOptions al método startTransaction(). Las transacciones se ejecutan dentro de sesiones, que son agrupaciones de operaciones de lectura o escritura relacionadas que se pretende ejecutar de forma secuencial.

Tip

Para obtener más información sobre las sesiones, consulta Sesiones del servidor en el manual del servidor de MongoDB.

El ejemplo configura los siguientes ajustes:

  • primary preferencia de lectura: las operaciones de lectura recuperan datos del miembro del conjunto de réplicas principal.

  • MAJORITY nivel de consistencia de lectura: Las operaciones de lectura devuelven los datos más recientes de la instancia que se han escrito en la mayoría de los miembros del set de réplicas.

  • W1 Preocupación de escritura: el miembro principal del conjunto de réplicas debe reconocer la operación de escritura.

mongoClient.startSession().use { session ->
try {
// Sets transaction read and write settings
val txnOptions = TransactionOptions.builder()
.readPreference(ReadPreference.primary())
.readConcern(ReadConcern.MAJORITY)
.writeConcern(WriteConcern.W1)
.build()
runBlocking {
session.startTransaction(txnOptions)
// Specify transaction operations here
session.commitTransaction()
}
} catch (e: Exception) {
println("Transaction failed: ${e.message}")
}
}

Este ejemplo muestra cómo establecer la preferencia de lectura, la preocupación de lectura y la preocupación de escritura de una base de datos llamada test_database encadenando métodos setter al método getDatabase(). El código configura los siguientes ajustes:

  • primaryPreferred preferencia de lectura: las operaciones de lectura recuperan datos del miembro del conjunto de réplicas principal o de miembros secundarios si el principal no está disponible.

  • AVAILABLE Preocupación de lectura: las operaciones de lectura devuelven los datos más recientes de la instancia sin garantizar que los datos se hayan escrito en la mayoría de los miembros del conjunto de réplicas.

  • MAJORITY nivel de confirmación de escritura (write concern): La mayoría de todos los miembros del set de réplicas deben reconocer la operación de escritura.

val database = mongoClient.getDatabase("test_database")
.withReadPreference(ReadPreference.primaryPreferred())
.withReadConcern(ReadConcern.AVAILABLE)
.withWriteConcern(WriteConcern.MAJORITY)

Este ejemplo muestra cómo configurar la preferencia de lectura, el nivel de consistencia de lectura y el nivel de confirmación de escritura (write concern) de una colección llamada test_collection, encadenando métodos setters al método getCollection(). El código configura la siguiente configuración:

  • secondaryPreferred preferencia de lectura: Las operaciones de lectura recuperan datos de los miembros secundarios del set de réplicas, o de los miembros primarios si no se dispone de miembros secundarios.

  • AVAILABLE Preocupación de lectura: las operaciones de lectura devuelven los datos más recientes de la instancia sin garantizar que los datos se hayan escrito en la mayoría de los miembros del conjunto de réplicas.

  • UNACKNOWLEDGED nivel de confirmación de escritura (write concern): Los miembros del conjunto de réplicas no necesitan reconocer la operación de escritura.

val collection = database.getCollection<Document>("test_collection")
.withReadPreference(ReadPreference.secondaryPreferred())
.withReadConcern(ReadConcern.AVAILABLE)
.withWriteConcern(WriteConcern.UNACKNOWLEDGED)

Las siguientes secciones describen formas de seguir personalizando cómo el driver de Kotlin enruta las operaciones de lectura.

Puede especificar una preferencia de lectura al conectarse a un clúster fragmentado. MongoDB utiliza la fragmentación para dividir los conjuntos de datos por rangos de claves y distribuir los datos entre varias instancias de base de datos. Un clúster fragmentado, o el conjunto de nodos en una implementación fragmentada, incluye los siguientes componentes:

  • Partición: Un set de réplicas que contiene un subconjunto de los datos particionados.

  • Mongos: un enrutador de consultas que proporciona una interfaz entre su aplicación y el clúster fragmentado.

  • Servidores de configuración: servidores que almacenan la configuración y los metadatos del clúster.

Tip

Para obtener más información sobre los clústeres fragmentados, consulte Fragmentación en el manual del servidor MongoDB.

Al leer de las particiones del set de réplicas, mongos aplica su preferencia de lectura especificada. La preferencia de lectura se reevalúa para cada operación.

El siguiente ejemplo muestra cómo conectarse a un clúster fragmentado y especificar una preferencia de lectura secondary en su cadena de conexión:

val shardedClient = MongoClient.create(
"mongodb://user:password@mongos1.example.com,mongos2.example.com/?readPreference=secondary"
)

En el servidor de MongoDB, se pueden aplicar etiquetas clave-valor a los miembros del set de réplicas según los criterios que elija. Luego, puedes utilizar esas etiquetas para dirigirte a uno o más miembros para una operación de lectura.

De forma predeterminada, el controlador de Kotlin ignora las etiquetas al elegir un miembro para leer. Para indicarle que prefiera ciertas etiquetas, páselas como una lista a su método de configuración de preferencias de lectura.

Supongamos que está conectado a un conjunto de réplicas que contiene miembros alojados en varios centros de datos en Estados Unidos. Quiere que el controlador prefiera las lecturas de los miembros del conjunto de réplicas secundario en el siguiente orden:

  1. Miembros del centro de datos de Nueva York, etiquetados con ("dc", "ny")

  2. Nodos del centro de datos de San Francisco, etiquetados con ("dc", "sf")

  3. Cualquier miembro secundario

Este ejemplo de código pasa una lista de etiquetas que representan a los miembros anteriores del set de réplicas al método setter ReadPreference.secondary(). Luego, el código pasa la información de preferencia de lectura al método withReadPreference() para establecer el orden de lectura en la base de datos:

val tag1 = TagSet(Tag("dc", "ny"))
val tag2 = TagSet(Tag("dc", "sf"))
val tag3 = TagSet() // Empty tag set as fallback
val readPref = ReadPreference.secondary(listOf(tag1, tag2, tag3))
val taggedDb = mongoClient.getDatabase("test_database")
.withReadPreference(readPref)

Al conectarse a un clúster particionado o a un set de réplicas, el driver de Kotlin utiliza el balanceo de carga para gestionar las solicitudes de lectura y escritura. El balanceo de carga permite al driver distribuir estas solicitudes entre varios servidores, lo que evita sobrecargar cualquier servidor y asegura un rendimiento óptimo.

Al conectarse a un clúster de fragmentación, el controlador de Kotlin determina la instancia de mongos más cercana calculando cuál tiene el menor tiempo de regreso de red. Luego, el driver determina la ventana de latencia sumando el tiempo de ida y vuelta promedio de este mongos al valor localThresholdMS. El controlador equilibra la carga de las solicitudes entre hasta dos instancias aleatorias de mongos que están dentro de la ventana de latencia. Para cada solicitud, el controlador elige el servidor con la menor carga de operación determinando su valor operationCount.

Cuando se conecta a un set de réplicas, el driver de Kotlin selecciona primero los miembros del set de réplicas de acuerdo a tu preferencia de lectura. Luego, el driver sigue el mismo proceso que se describió en el párrafo anterior. Tras calcular la ventana de latencia, el controlador selecciona hasta dos miembros del set de réplicas aleatorias que caen dentro de la ventana y elige el nodo con el menor valor de operationCount para recibir la solicitud.

Tip

Para obtener más información sobre el balanceo de carga, consulte Balanceador de clúster shardeado en el manual del servidor de MongoDB.

El driver de Kotlin utiliza el valor umbral local para calcular la ventana de latencia para la selección del servidor. Este valor determina los servidores que son elegibles para recibir solicitudes de lectura y guardado.

De forma predeterminada, el driver utiliza únicamente mongos instancias o miembros del set de réplicas cuyos tiempos de ping están dentro de 15 milisegundos del servidor más cercano. Para distribuir las lecturas entre servidores con mayores latencias, configure la opción localThreshold en una instancia MongoClientSettings o la opción localThresholdMS en su URI de conexión.

Nota

Al seleccionar miembros del set de réplicas de una sola instancia mongos, el driver de Kotlin ignora la opción localThresholdMS. En este caso, utiliza la opción de línea de comando localThreshold.

El siguiente ejemplo se conecta a un set de réplicas y especifica un umbral local de 35 milisegundos. Elija el MongoClientSettings o la pestaña Connection URI para ver el código correspondiente para cada enfoque:

val latencySettings = MongoClientSettings.builder()
.applyConnectionString(ConnectionString("mongodb://localhost:27017/"))
.applyToClusterSettings { builder ->
builder.localThreshold(35, TimeUnit.MILLISECONDS)
}
.build()
val latencyClient2 = MongoClient.create(latencySettings)
val latencyClient1 = MongoClient.create(
"mongodb://localhost:27017/?replicaSet=repl0&localThresholdMS=35"
)

En el ejemplo anterior, el driver de Kotlin distribuye las lecturas entre los nodos coincidentes dentro de 35 milisegundos del tiempo de ping del nodo más cercano.

El driver de Kotlin reintenta automáticamente algunas operaciones de lectura y guardado una sola vez si fallan debido a un error de red o del servidor.

Puedes desactivar explícitamente las lecturas o la escritura reintentable estableciendo la opción retryReads o retryWrites en false en una instancia MongoClientSettings. También puede establecer las opciones retryReads o retryWrites en el URI de su conexión.

El siguiente ejemplo establece tanto las lecturas como las escrituras reintentables en false. Selecciona la pestaña MongoClientSettings o Connection URI para ver el código correspondiente a cada enfoque:

val retrySettings = MongoClientSettings.builder()
.applyConnectionString(ConnectionString("mongodb://localhost:27017/"))
.retryReads(false) // Disables automatic retries of read operations
.retryWrites(false) // Disables automatic retries of write operations
.build()
val retryClient = MongoClient.create(retrySettings)
val retryUri = "mongodb://localhost:27017/?retryReads=false&retryWrites=false"
val retryUriClient = MongoClient.create(retryUri)

Para obtener más información sobre las operaciones de lectura con reintento compatibles, consulta Lecturas reintentables en el manual del servidor MongoDB. Para obtener más información sobre las operaciones de escritura reintentables compatibles, consulta Escrituras reintentables en el manual del servidor MongoDB.

Para aprender más sobre cualquiera de los métodos o tipos analizados en esta guía, consulta la siguiente documentación de API:

Volver

Transacciones

En esta página