Las bases de datos modernas deben tener la capacidad de capturar y reaccionar a los datos a medida que fluyen en tiempo real. Esto explica por qué MongoDB tiene una característica llamada MongoDB Change Streams responsable de capturar y responder a los datos en tiempo real. Change Streams es una característica introducida para transmitir información desde la aplicación a la base de datos en tiempo real. Se basa en un marco de agregación que supervisa las colecciones y permite que se produzcan cambios en la base de datos y en la colección de la base de datos. Además, MongoDB Change Stream puede capturar datos de sensores IOT y actualizar informes como cambios de datos operativos en una empresa. Este blog abrirá un discurso sobre MongoDB Change Stream y cambiará las recomendaciones en producción.
MongoDB Change Streams y Droping Collection
Cambiar el nombre o eliminar una base de datos o una colección provocará el cierre del cursor si hubo un flujo de cambios abierto que funciona en contra de la colección eliminada. Cambiar el nombre o soltar una colección hace que el cursor con FullDocument:updateLookup devuelva nulo en cualquier documento de búsqueda dado. Se produce un error si se intenta reanudar después de descartar una base de datos con un flujo de cambios en ejecución.
Además, se pierden todos los cambios en los datos realizados antes de cambiar el nombre de una colección con un flujo de cambios en ejecución. El límite de documentos para el flujo de cambios sigue siendo de 16 MB BSON; por lo tanto, no se aceptan documentos de más de 16 MB. Si uno intenta trabajar con un documento de más de 16 MB, la notificación falla y el documento se reemplaza con otro documento que cumple con el límite establecido.
Cuando una colección o base de datos con flujos de cambios abiertos se descarta o se cambia de nombre, los cursores de flujo de cambios tienden a cerrarse a medida que avanzan a ese punto en el registro de operaciones. Si cambia los cursores de flujo con el documento completo, la opción updateLookup puede devolver nulo al documento de búsqueda.
Por lo tanto, un intento de reanudar flujos de cambios en una colección que se ha descartado generará un error. Cualquier ocurrencia de cambios de datos en la colección entre el último evento del flujo de cambios capturado y el evento de eliminación de la colección se pierde.
Los documentos de respuesta de cambio de flujo deben cumplir con el límite de documentos BSON de 16 MB. Dependiendo del tamaño de los documentos en la colección en la que está abriendo el flujo de cambios, las notificaciones pueden fallar si el documento de notificación resultante tiene más de 16 MB. Un buen ejemplo son las operaciones de actualización en los flujos de cambios configurados para devolver un documento completamente actualizado o reemplazar/insertar procesos con el documento en el límite o ligeramente por debajo del límite.
MongoDB Change Stream y conjuntos de réplicas
Un conjunto de réplicas de MongoDB es una colección de procesos en MongoDB cuyo conjunto de datos no cambia; es decir, el conjunto de datos sigue siendo el mismo. En el caso de conjuntos de réplicas que tienen miembros árbitros, es probable que los flujos de cambios permanezcan inactivos si no hay disponibles suficientes miembros con los datos para que la mayoría no pueda realizar las operaciones. Por ejemplo, podemos considerar un conjunto de réplicas que tiene tres miembros con dos nodos que contienen datos junto con un árbitro. En caso de que el secundario esté inactivo, por ejemplo, como resultado de una falla, actualización o mantenimiento, será imposible que las operaciones de escritura se comprometan en su mayoría. El flujo de cambios permanecerá abierto pero no enviará notificaciones. En el escenario en cuestión, la aplicación puede ponerse al día con todas las operaciones que han tenido lugar en el período de tiempo de inactividad, siempre que la última operación recibida por la aplicación todavía esté en el registro de operaciones de ese conjunto de réplicas en particular. Además, el comando rs.printReplicationInfo() se usa para recuperar datos de oplog; los datos recuperados incluyen una gama de operaciones y tamaño de oplog.
Si el tiempo de inactividad se estima significativamente, por ejemplo, para realizar una actualización o en el caso de un desastre, aumentar el tamaño del registro de operaciones será la mejor opción para retener las operaciones por un período mayor a el tiempo de inactividad aproximado. Para recuperar información de estado de oplog, el comando utilizado es printReplicationInfo(). El comando recuperará no solo la información de estado del registro de operaciones, sino también el tamaño del registro de operaciones y el intervalo de tiempo de las operaciones.
MongoDB Change Streams Disponibilidad
Los flujos de cambios de MongoDB están disponibles para conjuntos de réplicas y clústeres fragmentados:habilitación "mayoritaria" de preocupación de lectura, motor de almacenamiento y versión de protocolo de conjunto de réplicas. Habilitación "mayoritaria" de preocupación de lectura:a partir de MongoDB versión 4.2 y superior, se puede acceder a los flujos de cambios a pesar de las circunstancias prevalecientes del soporte de preocupación de lectura "mayoritaria", lo que significa que el soporte de preocupación mayoritaria de lectura se puede habilitar o deshabilitar. En MongoDB versión 4.0 y En versiones anteriores, los flujos de cambios solo están disponibles si está activada la compatibilidad con inquietudes de lectura "mayoritarias".
- Motor de almacenamiento:el motor de almacenamiento WiredTiger es el tipo de motor de almacenamiento utilizado por los conjuntos de réplicas y los clústeres fragmentados.
- Versión del protocolo del conjunto de réplicas:los conjuntos de réplicas y los clústeres fragmentados siempre deben usar la versión 1 del protocolo del conjunto de réplicas (pv1).
Clústeres fragmentados de MongoDB
Los clústeres fragmentados en MongoDB consisten en fragmentos, mongos y servidores de configuración. Un fragmento consta de un subconjunto de datos fragmentados. En el caso de MongoDB 3.6, los fragmentos se utilizan como un conjunto de réplicas. Mongos proporciona una interfaz entre los clústeres fragmentados y las aplicaciones cliente; mongos juega el papel de un enrutador de consultas. A partir de MongoDB versión 4.4 y superior, mongos admite lecturas protegidas para reducir las latencias. Los servidores de configuración son las ubicaciones de almacenamiento para los ajustes de configuración del clúster y los metadatos.
Los flujos de cambios usan un reloj lógico global para proporcionar un ordenamiento global de los cambios en los fragmentos. MongoDB garantiza que se mantenga el orden de los cambios y que las notificaciones del flujo de cambios se puedan interpretar de forma segura en el orden en que se recibieron. Por ejemplo, el cursor del flujo de cambios abierto contra un clúster de 3 fragmentos devuelve las notificaciones del cambio relacionadas con el orden total de los cambios en los tres fragmentos.
Para garantizar el orden total de los cambios, Mongos verifica con cada fragmento para ver si ha visto cambios más recientes para cada notificación de cambio. Es probable que los clústeres fragmentados con uno o varios fragmentos con poca o ninguna actividad de recopilación o que estén "fríos" tengan efectos negativos en el tiempo de respuesta del flujo de cambios, ya que los mongos aún tienen que consultar esos fragmentos fríos para garantizar el orden total de los cambios. Este efecto puede ser más evidente cuando los fragmentos están distribuidos geográficamente o cuando las cargas de trabajo con la mayoría de las operaciones ocurren en un subconjunto de fragmentos en un clúster. Si la colección fragmentada tiene un alto nivel de actividad, es posible que los mongos no puedan realizar un seguimiento de los cambios en todos los fragmentos. Considere usar filtros de notificación para este tipo de recopilación, por ejemplo, pasando la canalización $match, que está configurada para filtrar solo las operaciones de inserción.
En el caso de colecciones fragmentadas, es probable que las operaciones de actualización multi:adecuadas provoquen flujos de cambios que se abren en la colección para enviar notificaciones de documentos huérfanos. Desde el momento en que se fragmenta una colección sin fragmentar hasta el momento en que el flujo de cambios llega al primer fragmento de migración, la clave del documento en el documento de notificación del flujo de cambios incluye solo la identificación del documento y no la clave de fragmento completa.
Conclusión
El propósito de los flujos de cambio es hacer posible que los datos de la aplicación cambien en tiempo real, sin el riesgo de acechar el registro de operaciones y sin ningún rastro de complejidad. Las aplicaciones de MongoDB utilizan flujos de cambios para firmar los cambios de datos en una base de datos, una colección o la implementación, y reaccionar inmediatamente ante ellos. Dado que los flujos de cambios utilizan el marco de agregación, las aplicaciones pueden filtrar los cambios específicos y convertir las notificaciones por sí mismas.
