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 Atlas Funciones y puede reenviar eventos a manejadores externos mediante Amazon Web Services EventBridge.

Utilice activadores de base de datos para implementar interacciones de datos basadas en eventos. Por ejemplo, puede actualizar automáticamente la información de un documento cuando cambia un documento relacionado o enviar una solicitud a un servicio externo cada vez que se inserta un nuevo documento.

Los activadores de bases de datos utilizan MongoDB Flujos de cambios para monitorear cambios en tiempo real en una colección. Un flujo de cambios 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 cambios para cada colección con al menos un disparador habilitado. Si habilita varios disparadores para una colección, todos comparten el mismo flujo de cambios.

Importante

Limitaciones del flujo de cambios

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 se puede definir un disparador de base de datos en un clúster Flex o en una instancia de base de datos federada porque no admiten flujos de cambio.

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 administrar desencadenantes, debes tener Project Trigger Manager o un acceso superior.

Crear un disparador 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, ve a Triggers página.
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 Desencadenantes.
Haga clic en Add Trigger para abrir la página de configuración del disparador.
Selecciona el tipo de activador Database.

Configura el activador y haz clic en Save.

Campo	Configuración
Trigger Type	Database or Scheduled
Watch Against	Collection, Database, 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:
Utilice su 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>
```
De forma predeterminada, el comando extrae los archivos al directorio de trabajo actual. Puede especificar una ruta de directorio con el indicador opcional --local.
Agregue un archivo de configuración de activación de base de datos al triggers subdirectorio en los archivos de su aplicación local.
Implementa tus cambios:
Ejecute el siguiente comando para implementar sus cambios:
```
appservices push
```

Nota

Atlas no impone nombres de archivo específicos para los archivos de configuración de los disparadores. Sin embargo, una vez importados, Atlas renombrará cada archivo de configuración para que coincida con el nombre del disparador que define.

Configuración

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

Detalles del disparador

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
Deployment, cuando se producen cambios de implementación en un clúster específico.
Si selecciona el tipo de origen Implementación,no se supervisan los cambios en las siguientes bases de datos:
- 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 fuente de 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 Cambiar el nombre de la colección Descartar Colección shardCollection Colección Reshard 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 TypeLos tipos de operaciones que ocurren en el clúster y que hacen que el disparador se active. Seleccione los tipos de operaciones a los que desea que responda el disparador. 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 un overhead de almacenamiento adicional que puede afectar el rendimiento. Si no tienes un caso de uso específico para preimágenes en una colección, deberías inhabilitarlas. 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 está habilitado, los eventos de activación se procesan en el orden en que ocurren. Si está deshabilitado, los eventos se pueden procesar en paralelo, lo cual es más rápido cuando ocurren muchos eventos simultáneamente. 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 Advanced sección, están 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 de proyecto inclusiva especifica los campos que se incluirán en cada documento de evento de cambio. La expresión es un objeto que asigna el nombre de los campos a un 1 valor. Si no se incluye un campo, este no se incluirá 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 excluirán de cada documento de evento de cambio. La expresión es un objeto que asigna el nombre de los campos a incluir a 0 un. 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 de igualdad completa para los documentos incrustados en una expresión de coincidencia. Si desea que un campo específico coincida con un documento incrustado, consulte el campo directamente mediante la notación de puntos. Para más información, consulte Consulta en 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 su clúster MongoDB Atlas vinculado.

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 en 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 (solo tipos de desencadenadores de implementación y base de datos)	Representa la colección de modificación.
Cambiar el nombre de la colección (solo tipos de desencadenadores de implementación y base de datos)	Representa la colección que está siendo renombrada.
Descartar colección (solo tipos de base de datos y activadores de implementación)	Representa una colección que se está eliminando.
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 desencadenadores de implementación y de base de datos)	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á eliminando.
Descartar base de datos (solo tipo de activador de implementación)	Representa una base de datos que se está descartando.

Los objetos de evento de cambio 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 activador de base de datos que escucha los eventos de cambio de Update en la colección store.orders. Cuando el Activador detecta un Update evento, pasa el objeto de evento de cambio a su función asociada, textShippingUpdate. La Función verifica el evento de cambio en busca de cualquier modificación en el campo shippingLocation y, si este se actualiza, 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 del registro de operaciones que contiene el token de reanudación. El siguiente evento coincidente no tendrá el token de reanudación, por lo que el disparador no podrá 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 disparador 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 activador 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.

Puede reiniciar un disparador suspendido desde la interfaz de usuario de Atlas o con la 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 Desencadenantes.

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

Utilice su 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>"

Extraiga los últimos archivos de configuración de su aplicación

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

appservices pull --remote=<App ID>

De forma predeterminada, el comando extrae 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

Este es el momento en el que se creó o modificó por última vez el disparador.

Ú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 activadores no ordenados ejecutan funciones en paralelo si es posible, lo que puede ser significativamente más rápido (dependiendo de su caso de uso), pero no garantiza que se produzcan múltiples ejecuciones de una función activadora en el orden del evento.

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 computacional pueden degradar el rendimiento de Trigger dependiendo de la configuración de su clúster.

Para evitar la sobrecarga de almacenamiento y procesamiento de las preimágenes, debe deshabilitarlas para toda la colección subyacente de MongoDB. Esta configuración es independiente de la configuración de preimágenes de cualquier disparador 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 saber cómo hacerlo,consulte Deshabilitar preimágenes para una colección.

Uso de expresiones de coincidencia para limitar las llamadas de activador

Puede limitar el número de invocaciones del disparador especificando una expresión $match en el Match Expression campo. Atlas evalúa la expresión de coincidencia con el documento del evento de cambio e invoca el disparador 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 consulta utilizando la sintaxis de consulta de lectura de MongoDB.

Recomendamos usar expresiones de coincidencia solo cuando el volumen de eventos de activación represente un problema de rendimiento considerable. Hasta entonces, reciba todos los eventos y gestione cada uno individualmente en el código de la función de activación.

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, use mongosh para realizar cambios en algunos documentos de prueba en la colección.
Observe lo que el flujo de cambio filtra dentro y fuera.

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

En el Project Expression campo, limite la cantidad de campos que procesa el disparador mediante una expresión $project.

Nota

El proyecto es solo inclusivo

Al usar activadores, una expresión de proyección es solo inclusiva. El proyecto no admite la combinación de inclusiones y exclusiones. La expresión del proyecto debe ser inclusiva, ya que los activadores requieren que se operationType incluya.

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