Activadores de base de datos

Los activadores de base de datos permiten ejecutar lógica del lado del servidor cada vez que ocurre un cambio en la base de datos en un clúster vinculado de MongoDB Atlas. Se pueden configurar Triggers en colecciones individuales, bases de datos completas y en todo el clúster.

A diferencia de los activadores de base de datos SQL, que se ejecutan en el servidor de la base de datos, los activadores de base de datos de Atlas se ejecutan en una capa de computación sin servidor que se escala independientemente del servidor de la base de datos. Los disparadores llaman automáticamente a las funciones de Atlas y pueden reenviar los eventos a controladores externos a través de AWS EventBridge.

Usa activadores de base de datos para implementar procesos de datos impulsados por eventos. Por ejemplo, puedes actualizar automáticamente la información en un documento cuando un documento relacionado cambie o enviar una solicitud a un servicio externo cada vez que se inserte un nuevo documento.

Los disparadores de base de datos utilizan flujos de cambio de MongoDB para detectar cambios en tiempo real en una colección. Un flujo de cambio es una serie de eventos de base de datos que describen una operación en un documento de la colección. La aplicación abre un único flujo de cambio para cada colección con al menos un disparador habilitado. Si habilita varios disparadores para una colección, todos comparten el mismo flujo de cambio.

Importante

Limitaciones de Change Stream

Existen límites en el número total de flujos de cambios que puedes abrir en un clúster, dependiendo del tamaño del clúster. Para obtener más información, consulta limitaciones del flujo de cambios.

Además, no puedes definir un activador de base de datos en un Flex clúster o una instancia federada de base de datos porque no se soportan streams de cambios.

Usted controla qué operaciones hacen que se dispare un activador y qué sucede cuando lo hace. Por ejemplo, puedes ejecutar una función cada vez que un campo específico de un documento se actualice. La función puede acceder al evento de cambio completo, por lo que siempre sabes qué cambió. También puedes pasar el evento de cambio a AWS EventBridge para gestionar el evento fuera de Atlas.

Los triggers permiten utilizar expresiones $match para filtrar eventos de cambios y expresiones $project para limitar los datos incluidos en cada evento.

Advertencia

En la implementación y a nivel de base de datos, es posible configurar Disparadores de manera que otros Disparadores se activen, lo que provoca recursividad. Ejemplos incluyen un activador a nivel de base de datos que escribe en una colección dentro de la misma base de datos, o un registrador o reenviador de registros a nivel de clúster que escribe registros en otra base de datos dentro del mismo clúster.

Permisos requeridos

Para crear y gestionar triggers, debes tener Project Trigger Manager o un acceso superior.

Crear un activador de base de datos

Puedes crear un activador de base de datos desde la Interfaz de Usuario de Atlas o con la App Services CLI.

En Atlas, diríjase a la página Triggers.
1. Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.
2. Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.
3. En la barra lateral, haz clic en Triggers en la sección Streaming Data.
Se muestra la página de Triggers.
Haz clic en Add Trigger para abrir la página de configuración del activador.
Selecciona el tipo de activador Database.

Configura el activador y haz clic en Save.

Campo	Configuración
Trigger Type	Database or Scheduled
Watch Against	CollectionDatabase, o Deployment.
Cluster Name	Nombre que identifica el clúster.
Database Name	Nombre que identifica la base de datos.
Collection Name	Nombre que identifica la colección.
Operation Type	Operación que hace que el activador se active.

Autenticar a un usuario MongoDB Atlas:
Usa tu Clave API de administración de MongoDB Atlas para iniciar sesión en la CLI de App Services:
```
appservices login --api-key="<API KEY>" --private-api-key="<PRIVATE KEY>"
```
Solicita los archivos de configuración más recientes de tu aplicación:
Ejecute el siguiente comando para obtener una copia local de sus archivos de configuración:
```
appservices pull --remote=<App ID>
```
Por defecto, el comando arrastra los archivos al directorio de trabajo actual. Puede especificar una ruta de directorio con el indicador opcional --local.
Agrega un archivo de configuración de activador de base de datos al subdirectorio triggers en los archivos de tu app local.
Implementa tus cambios:
Ejecute el siguiente comando para implementar sus cambios:
```
appservices push
```

Nota

Atlas no aplica nombres de archivo específicos para los archivos de configuración de activadores. Sin embargo, una vez importado, Atlas renombrará cada archivo de configuración para que coincida con el nombre del activador que define.

Configuración

Los activadores de base de datos tienen las siguientes opciones de configuración:

Detalles del activador

Dentro de la sección Trigger Details, puede seleccionar el alcance que desea que el activador Watch Against, según el nivel de granularidad que desee. Tus opciones son:

Collection, cuando se produce un cambio en una colección específica
Database, cuando se produce un cambio en cualquier colección en una base de datos especificada
Deploymentcuando se produzcan cambios de implementación en un clúster especificado.

Si seleccionas el tipo de fuente de Implementación, las siguientes bases de datos no se supervisan para detectar cambios:
- Las bases de datos admin admin, local y config
- Las bases de datos de sincronización __realm_sync y __realm_sync_<app_id>
Importante
El tipo de origen a nivel de implementación solo está disponible en niveles dedicados.

Según el tipo de fuente que utilices, las opciones adicionales varían. La siguiente tabla describe estas opciones.

Tipo de fuente	opciones
Collection	Cluster Name. El nombre del clúster de MongoDB con el que está asociado el activador. Database NameLa base de datos de MongoDB que contiene la colección vigilada. Collection Name. La colección de MongoDB que se monitoreará. opcional. Si deja esta opción en blanco, el tipo de origen cambia a "Base de datos". Operation TypeLos tipos de operación que causan que el activador se accione. Selecciona los tipos de operación a los que quieres que el activador responda. Las opciones incluyen: Insert Update Reemplaza Borrar Nota: Las operaciones de actualización ejecutadas desde MongoDB Compass o MongoDB Atlas Data Explorer reemplazan completamente el documento anterior. Como resultado, las operaciones de actualización de estos clientes generan `Replace` eventos de cambio en lugar de `Update` eventos. Full Document. Si está habilitado, los eventos de cambio de `Update` incluyen la última versión mayoría confirmada del documento modificado después de que se haya aplicado el cambio en el campo `fullDocument`. Nota: Independientemente de esta configuración, los eventos de Insertar y Reemplazar siempre incluyen el campo `fullDocument`. Los eventos de borrar nunca incluyen el campo `fullDocument`. Document PreimageCuando está habilitado, los eventos de cambio incluyen una copia del documento modificado desde inmediatamente antes de que el cambio se aplicara en el campo `fullDocumentBeforeChange`. Esto tiene un impacto en el performance. Todos los eventos de cambio, excepto los eventos `Insert`, incluyen la preimagen del documento.
Database	Cluster Name. El nombre del clúster de MongoDB con el que está asociado el activador. Database Name. La base de datos MongoDB a observar. opcional. Si dejas esta opción en blanco, el tipo de fuente cambia a `Deployment` a menos que estés en un nivel compartido, en cuyo caso Atlas no te permitirá guardar el activador. Operation TypeLos tipos de operación que causan que el activador se accione. Selecciona los tipos de operación a los que quieres que el activador responda. Las opciones incluyen: Crear colección Modificar colección renameCollection Descartar Colección shardCollection reshardCollection Refinar la clave de partición de la colección Nota: Las operaciones de actualización ejecutadas desde MongoDB Compass o MongoDB Atlas Data Explorer reemplazan completamente el documento anterior. Como resultado, las operaciones de actualización de estos clientes generarán `Replace` eventos de cambio en lugar de `Update` eventos. Full Document. Si está habilitado, los eventos de cambio de `Update` incluyen la última versión mayoría confirmada del documento modificado después de que se haya aplicado el cambio en el campo `fullDocument`. Nota: Independientemente de esta configuración, los eventos de Insertar y Reemplazar siempre incluyen el campo `fullDocument`. Los eventos de borrar nunca incluyen el campo `fullDocument`.
Deployment	Cluster Name. El nombre del clúster de MongoDB con el que está asociado el activador. Operation Type. Los types de operación que se producen en el clúster y que hacen que se active el activador. Selecciona los tipos de operaciones a los que quieres que responda el activador. Las opciones incluyen: Descartar base de datos Full Document. Si está habilitado, los eventos de cambio de `Update` incluyen la última versión mayoría confirmada del documento modificado después de que se haya aplicado el cambio en el campo `fullDocument`. Nota: Independientemente de esta configuración, los eventos de Insertar y Reemplazar siempre incluyen el campo `fullDocument`. Los eventos de borrar nunca incluyen el campo `fullDocument`.

Tip

Preimágenes y optimización del rendimiento

Las preimágenes requieren almacenamiento adicional, lo que puede afectar el rendimiento. Si no tiene un caso de uso específico para las preimágenes en una colección, debería deshabilitarlas. Para obtener más información, consulte Deshabilitar preimágenes a nivel de colección.

Las preimágenes de documentos son compatibles para las colecciones en clústeres Atlas no particionados que ejecutan MongoDB 4.4y versiones posteriores, y en clústeres Atlas particionados que ejecutan MongoDB 5.3 y versiones posteriores. Puedes actualizar un clúster no particionado (con preimágenes) a un clúster particionado, siempre que el clúster ejecute 5.3 o posterior.

Configuraciones de activador

Campo	Descripción
Auto-Resume	Si está activado, cuando el token de reanudación de este activador no se encuentra en el oplog del clúster, el activador reanuda automáticamente el procesamiento de eventos en el siguiente evento relevante del flujo de cambios. Todos los eventos de flujo de cambios desde que el activador fue suspendido hasta que se reanuda su ejecución, no causarán que el activador se active para esos eventos.
Event Ordering	Si se habilita, los eventos del activador se procesan en el orden en que se producen. Si está desactivado, los eventos pueden procesarse en paralelo, lo que resulta más rápido cuando muchos eventos ocurren al mismo tiempo. Si el ordenamiento de eventos está habilitado, se producirán múltiples ejecuciones de este activador de manera secuencial según las marcas de tiempo de los eventos de cambio. Si el ordenamiento de eventos está deshabilitado, se producirán múltiples ejecuciones de este activador de forma independiente. Consejo: para mejorar el rendimiento de los activadores que responden a operaciones masivas en la base de datos, desactiva la ordenación de eventos.
Skip Events On Re-Enable	Desactivado por defecto. Si está habilitado, los eventos de cambio ocurridos mientras este activador estaba deshabilitado no se procesarán.

Tipo de evento

Dentro de la sección Event Type, eliges la acción que se tomará cuando se active el activador. Puede elegir ejecutar una Función o usar AWS EventBridge.

Avanzado

Dentro de la sección Advanced, se encuentran disponibles las siguientes opciones de configuración opcionales:

Campo

Descripción

Project Expression

Una expresión $project que selecciona un subconjunto de campos de cada evento en el flujo de cambios. Puedes usar esto para optimizar la ejecución del activador.

La expresión es un objeto que asigna el nombre de los campos en el evento de cambio a 0, que excluye el campo, o a 1, que lo incluye. Una expresión puede tener valores de 0 o 1, pero no ambos juntos. Esto divide las proyecciones en dos categorías: inclusivas y exclusivas:

Una expresión inclusiva de proyecto especifica los campos a incluir en cada documento de evento de cambio. La expresión es un objeto que asigna el nombre de los campos a incluir a un 1. Si no incluyes un campo, no se incluye en el evento de cambio proyectado.

La siguiente proyección incluye solo los campos _id y fullDocument:
{ _id: 1, fullDocument: 1 }
Una expresión de proyecto exclusiva especifica los campos que se deben excluir de cada documento de evento de cambio. La expresión es un objeto que asigna el nombre de los campos a incluir a un 0. Si no se excluye un campo, este se incluye en el evento de cambio proyectado.

La siguiente proyección excluye los campos _id y fullDocument:
{ _id: 0, fullDocument: 0 }
No puedes excluir el campo operation_type con una proyección. Esto garantiza que el activador siempre pueda comprobar si debe ejecutarse para un tipo de operación de evento dado.

Match Expression

Un documento de expresión $match que Atlas utiliza para filtrar qué eventos de cambio provocan la activación del activador. El activador evalúa todos los objetos de eventos de cambio que recibe contra esta expresión de coincidencia y solo ejecuta si la expresión se evalúa como true para un evento de cambio dado.

MongoDB realiza una coincidencia exacta para documentos incrustados en una expresión de coincidencia. Si deseas hacer coincidir un campo específico en un documento incrustado, consulta el campo directamente utilizando la notación de puntos. Para obtener más información, consulte Query sobre documentos incrustados en el manual del servidor MongoDB.

Para optimizar el rendimiento, limita la cantidad de campos que el Activador procesa usando una expresión $match. Aprende más

Maximum Throughput

If the linked data source is a dedicated server (M10+ Tier), you can increase the maximum throughput beyond the default 10,000 concurrent processes.

Importante: Para habilitar el rendimiento máximo, debes desactivar la Ordenación de eventos.

Antes de aumentar el rendimiento máximo, considere si uno o más de sus Activadores están llamando a una API externa con limitación de tasa. Aumentar la tasa de activación puede resultar en exceder esos límites.

Aumentar el rendimiento también puede añadir una mayor carga de trabajo, afectando el rendimiento general del clúster.

Cambiar tipos de eventos

Los eventos de cambio de base de datos representan cambios individuales en una colección específica de tu clúster vinculado de MongoDB Atlas.

Cada evento de base de datos tiene el mismo tipo de operación y estructura que el objeto evento de cambio que fue emitido por el flujo de cambios subyacente. Los eventos de cambio tienen los siguientes tipos de operaciones:

Tipo de operación	Descripción
Insertar documento (Todos los tipos de activador)	Representa un nuevo documento añadido a la colección.
Actualizar documento (todos los tipos de activadores)	Representa un cambio a un documento existente en la colección.
Borrar documento (todos los tipos de activadores)	Representa un documento eliminado de la colección.
Reemplazar documento (Todos los tipos de activadores)	Representa un nuevo documento que reemplazó a un documento en la colección.
Crear colección (solo tipos de implementación y activador de base de datos)	Representa la creación de una nueva colección.
Modificar colección (sólo tipos de activador de base de datos y de implementación)	Representa la colección de modificación.
Renombrar colección (solo tipos de base de datos y activación de implementación)	Representa la colección que está siendo renombrada.
Descartar colección (solo tipos de base de datos y activadores de implementación)	Representa la eliminación de una colección.
Partición de colección (solo tipos de activadores de bases de datos e implementación)	Representa una colección que cambia de no fragmentada a fragmentada.
Refragmentar Colección (solo tipos de activadores de Base de Datos e Implementación)	Representa un cambio en el particionado de una colección.
Refina la clave de partición de la colección (solo para tipos de activadores de base de datos e implementación)	Representa un cambio en la clave de partición de una colección.
Crear índices (Solo tipos de bases de datos y activadores de implementación)	Representa la creación de un nuevo índice.
Descartar índices (solo tipos de base de datos y activadores de implementación)	Representa un índice que se está descartando.
Descartar base de datos (solo tipo de activador de implementación)	Representa una base de datos que se está descartando.

Los objetos de eventos de cambios de base de datos tienen la siguiente forma general:

{
   _id : <ObjectId>,
   "operationType": <string>,
   "fullDocument": <document>,
   "fullDocumentBeforeChange": <document>,
   "ns": {
      "db" : <string>,
      "coll" : <string>
   },
   "documentKey": {
     "_id": <ObjectId>
   },
   "updateDescription": <document>,
   "clusterTime": <Timestamp>
}

Ejemplo de activador de base de datos

Una tienda en línea quiere notificar a sus clientes cada vez que uno de sus pedidos cambie de ubicación. Registran cada pedido en la colección store.orders como un documento similar al siguiente:

{
  _id: ObjectId("59cf1860a95168b8f685e378"),
  customerId: ObjectId("59cf17e1a95168b8f685e377"),
  orderDate: ISODate("2018-06-26T16:20:42.313Z"),
  shipDate: ISODate("2018-06-27T08:20:23.311Z"),
  orderContents: [
    { qty: 1, name: "Earl Grey Tea Bags - 100ct", price: NumberDecimal("10.99") }
  ],
  shippingLocation: [
    { location: "Memphis", time: ISODate("2018-06-27T18:22:33.243Z") },
  ]
}

Para automatizar este proceso, la tienda crea un disparador de base de datos que detecta Update eventos de cambio en la store.orders colección. Cuando el disparador detecta un Update evento, pasa el objeto de evento de cambio a su función asociada,. textShippingUpdate La función comprueba si el evento de cambio ha cambiado el shippingLocation campo y, si se actualizó, envía un mensaje de texto al cliente con la nueva ubicación del pedido.

Campo	Configuración
Trigger Type	Database
Watch Against	Collection
Cluster Name	`Cluster0`
Database Name	`store`
Collection Name	`orders`
Operation Type	`Update Document`

Configuración de activador

{
  "type": "DATABASE",
  "name": "shippingLocationUpdater",
  "function_name": "textShippingUpdate",
  "config": {
    "service_name": "mongodb-atlas",
    "database": "store",
    "collection": "orders",
    "operation_types": ["UPDATE"],
    "unordered": false,
    "full_document": true,
    "match": {}
  },
  "disabled": false
}

textShippingUpdate

exports = async function (changeEvent) {
  // Destructure out fields from the change stream event object
  const { updateDescription, fullDocument } = changeEvent;
  // Check if the shippingLocation field was updated
  const updatedFields = Object.keys(updateDescription.updatedFields);
  const isNewLocation = updatedFields.some(field =>
    field.match(/shippingLocation/)
  );
  // If the location changed, text the customer the updated location.
  if (isNewLocation) {
    const { customerId, shippingLocation } = fullDocument;
    const mongodb = context.services.get("mongodb-atlas");
    const customers = mongodb.db("store").collection("customers");
    const { location } = shippingLocation.pop();
    const customer = await customers.findOne({ _id: customerId });
    const twilio = require('twilio')(
      // Your Account SID and Auth Token from the Twilio console:
      context.values.get("TwilioAccountSID"),
      context.values.get("TwilioAuthToken"),
    );
    await twilio.messages.create({
      To: customer.phoneNumber,
      From: context.values.get("ourPhoneNumber"),
      Body: `Your order has moved! The new location is ${location}.`
    })
  }
};

Disparadores suspendidos

Los activadores de base de datos pueden entrar en un estado suspendido como respuesta a un evento que impide que el flujo de cambios del disparador continúe. Los eventos que pueden suspender un activador incluyen:

Invalidar eventos, como dropDatabase, renameCollection o aquellos causados por una disrupción de red.
el token de reanudación requerido para reanudar el flujo de cambios ya no está en el oplogdel clúster. Los registros de la aplicación se refieren a esto como un error ChangeStreamHistoryLost.
una etapa $match filtra una entrada de oplog que contiene el token de reanudación del oplog. El siguiente evento coincidente no tendrá el token de reanudación, por lo que el activador no puede reanudarse.

En el evento de un activador suspendido o fallido, Atlas enviará un correo electrónico al propietario del proyecto alertándolo del problema.

Reanudar automáticamente un activador suspendido

Puedes configurar un activador para que se reanude automáticamente si se suspendió porque el token de reanudación ya no está en el oplog. El activador no procesa ningún evento perdido del flujo de cambios entre el momento en que se pierde el token de reanudación y cuando se completa el proceso de reanudación.

Al crear o actualizar un disparador de base de datos en la interfaz de usuario de Atlas:

Navegue a la página de configuración del activador que desea reanudar automáticamente si se suspende.
En la sección Advanced (Optional), seleccione Auto-Resume Triggers.
Guarda e implementa los cambios.

Reanudar manualmente un activador suspendido

Cuando reanudas manualmente un activador suspendido, la aplicación intentará reanudar el activador en el siguiente evento del flujo de cambios después de que este se haya detenido. Si el token de reanudación ya no está en el oplog del clúster, el activador debe iniciarse sin un token de reanudación. Esto significa que el activador comienza a escuchar nuevos eventos, pero no procesa ningún evento pasado que se haya perdido.

Puedes ajustar el tamaño de oplog para conservar el token de reanudación durante más tiempo después de una suspensión escalando tu clúster de |servicio|. Mantener un tamaño de oplog varias veces mayor que el pico de rendimiento de oplog de tu clúster (GB/hora) para reducir el riesgo de que el token de reanudación de un activador suspendido se caiga de la oplog antes de que el activador se ejecute. Consulta el rendimiento de tu clúster en el grafo Oplog GB/Hour en las |service| métricas del clúster.

Puedes reiniciar un activador suspendido desde la interfaz de usuario de Atlas o con la interfaz de línea de comandos (App Services CLI) de App Services.

En Atlas, ve a la página Triggers de tu proyecto.

Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.
Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Triggers en la sección Streaming Data.

Se muestra la página de Triggers.

Encuentra el activador suspendido

En la página de Triggers, encuentra el activador que deseas deshabilitar en la lista de activadores. Atlas marca los Triggers suspendidos con un Status de Suspended.

Reiniciar el activador

Haz clic en Restart en la columna Actions del activador. Puedes elegir reiniciar el activador con un token de reanudación del flujo de cambios o abrir un nuevo flujo de cambios.

Indique si desea utilizar o no un token de reanudación y luego haga clic en Resume Database Trigger.

Nota: Si utilizas un token de reanudación, Atlas intentará reanudar la corriente de cambios subyacente del activador en el evento inmediatamente posterior al último evento de cambio que haya procesado. Si tiene éxito, el activador procesa cualquier evento que haya ocurrido mientras estuvo suspendido. Si no utilizas un token de reanudación, el activador comenzará a escuchar nuevos eventos, pero no se activará para ningún evento que haya ocurrido mientras estuvo suspendido.

El activador de base de datos Modal en la Interfaz de Usuario

Autenticar a un usuario de MongoDB Atlas

Usa tu Clave API de administración de MongoDB Atlas para iniciar sesión en la CLI de App Services:

appservices login --api-key="<API KEY>" --private-api-key="<PRIVATE KEY>"

Extrae los archivos de configuración más recientes de tu aplicación

Ejecute el siguiente comando para obtener una copia local de sus archivos de configuración:

appservices pull --remote=<App ID>

Por defecto, el comando arrastra los archivos al directorio de trabajo actual. Puede especificar una ruta de directorio con el indicador opcional --local.

Verifique que el archivo de configuración del activador exista

Si exportas una nueva copia de tu aplicación, ya debería incluir un archivo de configuración actualizado para el activador suspendido. Puedes confirmar que el archivo de configuración existe buscando en el directorio /triggers un Archivo de configuración de activador con el mismo nombre que el activador.

Volver a implementar el activador

Después de verificar que el archivo de configuración del activador existe, envía la configuración a tu aplicación. Los servicios de aplicación intentan reiniciar automáticamente cualquier activador suspendido incluido en la implementación.

appservices push

Activar el reporte de horas

La lista de Triggers en la Interfaz de Usuario de Atlas muestra tres marcas de tiempo:

Última modificación

Esta es la hora en que se creó el activador o se cambió más recientemente.

Último latido

Atlas lleva el registro de la última vez que se ejecutó un activador. Si el activador no está enviando ningún evento, el servidor envía una comprobación de estado para garantizar que el token de reanudación del activador permanezca actualizado. El evento más reciente se muestra como el Latest Heartbeat.

Última vez que el clúster fue procesado

Atlas también realiza un seguimiento de Last Cluster Time Processed, que es la última vez que el flujo de cambios que respalda un activador emitió un evento. Será más antiguo que el Latest Heartbeat si no ha habido eventos desde el latido cardíaco más reciente.

Optimización del rendimiento

Desactivar la ordenación de eventos para operaciones de ráfaga

Considera deshabilitar la ordenación de eventos si tu activador se activa en una colección que recibe breves ráfagas de eventos (por ejemplo, insertando datos como parte de un trabajo por lotes diario).

Los disparadores ordenados esperan ejecutar una función para un evento particular hasta que las funciones de eventos anteriores hayan terminado de ejecutarse. Como consecuencia, los activadores ordenados están efectivamente limitados en cuanto a la velocidad por el tiempo de ejecución de cada función secuencial de activador. Esto puede causar un retraso significativo entre la aparición del evento de la base de datos en el flujo de cambios y la activación del activador. En ciertos casos extremos, los eventos de base de datos podrían caerse del oplog antes de que un activador ordenado de larga duración los procese.

Los Triggers sin orden ejecutan Functions en paralelo si es posible, lo que puede ser significativamente más rápido (dependiendo del caso de uso), pero no garantiza que varias ejecuciones de una Trigger Function ocurran en el orden de los eventos.

Desactivar preimágenes a nivel de colección

Las preimágenes de documentos requieren que tu clúster registre datos adicionales sobre cada operación en una colección. Una vez que activas preimágenes para cualquier activador en una colección, tu clúster almacena preimágenes para cada operación en la colección.

El espacio de almacenamiento adicional y la sobrecarga de cómputo pueden degradar el rendimiento del activador, dependiendo de la configuración de tu clúster.

Para evitar la sobrecarga de almacenamiento y computación de las preimágenes, debes desactivar las preimágenes para toda la colección subyacente de MongoDB. Esta es una configuración separada de la configuración de preimagen de cualquier activador individual.

Si se desactivan las preimágenes a nivel de colección, ningún activador activo podrá utilizar preimágenes en esa colección. Sin embargo, si elimina o desactiva todos los triggers de preimagen en una colección, entonces también puede desactivar las preimágenes a nivel de colección.

Para aprender cómo, consulta Deshabilitar preimágenes para una colección.

Uso de expresiones de coincidencia para limitar las llamadas de activador

Puedes limitar el número de invocaciones del activador especificando una expresión $match en el campo Match Expression. Atlas evalúa la expresión de coincidencia contra el documento del evento de cambio e invoca el activador solo si la expresión se evalúa como verdadera para el evento de cambio dado.

La expresión de coincidencia es un documento JSON que especifica las condiciones de query utilizando la Sintaxis de queries de lectura de MongoDB.

Recomendamos utilizar expresiones de coincidencia solo cuando el volumen de eventos de activador se convierta de manera medible en un problema de rendimiento. Hasta entonces, recibe todos los eventos y gestiónalos individualmente en el código de la función activador.

La forma exacta del documento de evento de cambio depende del evento que activó el activador. Para más detalles, consulta la referencia de cada tipo de evento:

La siguiente expresión de coincidencia permite que el activador se active solo si el objeto de evento de cambio especifica que el campo status en un documento cambió.

updateDescription es un campo de la objeto de evento de actualizar.

{
  "updateDescription.updatedFields.status": {
    "$exists": true
  }
}

La siguiente expresión de coincidencia permite que el activador se active solo cuando el campo needsTriggerResponse de un documento equivale a true. El campo fullDocument de los eventos insertar, actualizar y reemplazar representa un documento después de la operación dada. Para recibir el campo fullDocument, debe habilitar Full Document en su configuración del activador.

{
  "fullDocument.needsTriggerResponse": true
}

Expresiones de coincidencia de prueba

El siguiente procedimiento muestra una forma de probar si tu expresión de coincidencia funciona como se espera:

Descarga MongoDB Shell (mongosh) y úsalo para conectar a tu clúster.
Reemplaza DB_NAME con el nombre de tu base de datos, COLLECTION_NAME con el nombre de tu colección y YOUR_MATCH_EXPRESSION con la expresión de coincidencia que deseas probar. Pega lo siguiente en mongosh para abrir un flujo de cambios en una colección existente:
db.getSiblingDB(DB_NAME).COLLECTION_NAME.watch([{$match: YOUR_MATCH_EXPRESSION}]) while (!watchCursor.isClosed()) { if (watchCursor.hasNext()) { print(tojson(watchCursor.next())); } }
En otra ventana de terminal, utiliza mongosh para hacer cambios en algunos documentos de prueba en la colección.
Observe qué filtra el flujo de cambios.

Usa expresiones de proyecto para reducir el tamaño de los datos de entrada

En el campo Project Expression, limite el número de campos que procesa el activador usando una expresión $project.

Nota

El proyecto es exclusivamente inclusivo

Al utilizar los Triggers, una expresión de proyección es solo inclusiva. El proyecto no admite mezclar inclusiones y exclusiones. La expresión del proyecto debe ser inclusiva porque los disparadores requieren que incluyas operationType.

Si deseas excluir un solo campo, la expresión de proyección debe incluir todos los campos excepto el que deseas excluir. Solo puede excluir explícitamente _id, que se incluye por defecto.

Un activador está configurado con lo siguiente Project Expression:

{
  "_id": 0,
  "operationType": 1,
  "updateDescription.updatedFields.status": 1
}

El objeto de evento de cambio que Atlas pasa a la Función Activadora solo incluye los campos especificados en la proyección, como en el siguiente ejemplo:

{
  "operationType": "update",
  "updateDescription": {
    "updatedFields": {
      "status": "InProgress"
    }
  }
}

Tip

Ejemplos de Activadores en Github.

Volver

Atlas Triggers

Activadores programados