En las bases de datos , la captura de datos modificados ( CDC ) es un conjunto de patrones de diseño de software que se utilizan para determinar y realizar un seguimiento de los datos que han cambiado para que se puedan tomar medidas utilizando los datos modificados.
CDC es un enfoque para la integración de datos que se basa en la identificación, captura y entrega de los cambios realizados en las fuentes de datos empresariales.
La CDC ocurre a menudo en entornos de almacenamiento de datos, ya que capturar y preservar el estado de los datos a lo largo del tiempo es una de las funciones principales de un almacén de datos, pero la CDC se puede utilizar en cualquier base de datos o sistema de repositorio de datos.
Metodología
Los desarrolladores de sistemas pueden configurar los mecanismos CDC de varias formas y en una o en una combinación de capas del sistema, desde la lógica de la aplicación hasta el almacenamiento físico.
En un contexto CDC simplificado, un sistema informático tiene datos que se cree que han cambiado desde un punto anterior en el tiempo, y un segundo sistema informático necesita tomar medidas basándose en esos datos modificados. El primero es la fuente, el segundo es el objetivo. Es posible que el origen y el destino sean el mismo sistema físicamente, pero eso no cambiaría el patrón de diseño de manera lógica. Pueden existir varias soluciones CDC en un solo sistema.
Marcas de tiempo en filas
Las tablas cuyos cambios deben capturarse pueden tener una columna que represente la hora del último cambio. Nombres como LAST_UPDATE, etc. son comunes. Se considera que ha cambiado cualquier fila de cualquier tabla que tenga una marca de tiempo en esa columna que sea más reciente que la última vez que se capturaron los datos.
Las marcas de tiempo en las filas también se utilizan con frecuencia para el bloqueo optimista, por lo que esta columna suele estar disponible.
Números de versión en filas
Los diseñadores de bases de datos dan a las tablas cuyos cambios deben capturarse una columna que contiene un número de versión. Nombres como VERSION_NUMBER, etc. son comunes.
Una técnica consiste en marcar cada fila modificada con un número de versión. Se mantiene una versión actual para la tabla, o posiblemente un grupo de tablas. Esto se almacena en una construcción de apoyo, como una tabla de referencia. Cuando se produce una captura de cambios, se considera que han cambiado todos los datos con el número de versión más reciente. Una vez que se completa la captura de cambios, la tabla de referencia se actualiza con un nuevo número de versión.
(No confunda esta técnica con el control de versiones a nivel de fila utilizado para el bloqueo optimista . Para el bloqueo optimista, cada fila tiene un número de versión independiente, generalmente un contador secuencial. Esto permite que un proceso actualice atómicamente una fila e incremente su contador solo si otro proceso ha no incrementó el contador. Pero CDC no puede usar versiones de nivel de fila para buscar todos los cambios a menos que conozca la versión "inicial" original de cada fila. Esto no es práctico de mantener).
Indicadores de estado en filas
Esta técnica puede complementar o complementar las marcas de tiempo y el control de versiones. Puede configurar una alternativa si, por ejemplo, se configura una columna de estado en una fila de la tabla que indica que la fila ha cambiado (por ejemplo, una columna booleana que, cuando se establece en verdadero, indica que la fila ha cambiado). De lo contrario, puede actuar como complemento de los métodos anteriores, lo que indica que una fila, a pesar de tener un número de versión nuevo o una fecha posterior, aún no debe actualizarse en el objetivo (por ejemplo, los datos pueden requerir validación humana).
Hora / Versión / Estado en filas
Este enfoque combina los tres métodos discutidos anteriormente. Como se señaló, no es raro ver varias soluciones CDC en funcionamiento en un solo sistema; sin embargo, la combinación de tiempo, versión y estado proporciona un mecanismo particularmente poderoso y los programadores deben utilizarlos como un trío siempre que sea posible. Los tres elementos no son redundantes ni superfluos. Usarlos juntos permite una lógica como, "Capture todos los datos para la versión 2.1 que cambiaron entre el 1 de junio de 2005 a las 12:00 am y el 1 de julio de 2005 a las 12:00 am, donde el código de estado indica que está listo para la producción".
Disparadores en tablas
Puede incluir un patrón de publicación / suscripción para comunicar los datos modificados a varios destinos. En este enfoque, desencadena eventos de registro que suceden en la tabla transaccional en otra tabla de cola que luego se puede "reproducir". Por ejemplo, imagine una tabla de Cuentas, cuando las transacciones se toman en esta tabla, se dispararían activadores que luego almacenarían un historial del evento o incluso los deltas en una tabla de cola separada. La tabla de cola puede tener un esquema con los siguientes campos: Id, TableName, RowId, TimeStamp, Operation. Los datos insertados para nuestra muestra de Cuenta podrían ser: 1, Cuentas, 76, 02/11/2008 12:15 am, Actualización. Los diseños más complicados pueden registrar los datos reales que cambiaron. Esta tabla de cola podría entonces "reproducirse" para replicar los datos del sistema de origen a un destino.
[Se necesita más discusión]
Un ejemplo de esta técnica es el patrón conocido como disparador de registro .
Programacion de eventos
Codificar un cambio en una aplicación en los puntos apropiados es otro método que puede brindar un discernimiento inteligente de que los datos cambiaron. Aunque este método implica programación frente a disparadores "tontos" más fáciles de implementar, puede proporcionar un CDC más preciso y deseable, como solo después de COMMIT, o solo después de que ciertas columnas cambian a ciertos valores, justo lo que busca el sistema de destino.
Escáneres de registros
La mayoría de los sistemas de administración de bases de datos administran un registro de transacciones que registra los cambios realizados en el contenido de la base de datos y en los metadatos . Al escanear e interpretar el contenido del registro de transacciones de la base de datos, se pueden capturar los cambios realizados en la base de datos de una manera no intrusiva.
El uso de registros de transacciones para la captura de datos modificados presenta un desafío, ya que la estructura, el contenido y el uso de un registro de transacciones son específicos de un sistema de gestión de bases de datos. A diferencia del acceso a los datos, no existe un estándar para los registros de transacciones. La mayoría de los sistemas de administración de bases de datos no documentan el formato interno de sus registros de transacciones, aunque algunos proporcionan interfaces programáticas para sus registros de transacciones (por ejemplo: Oracle, DB2, SQL / MP, SQL / MX y SQL Server 2008).
Otros desafíos en el uso de registros de transacciones para la captura de datos de cambios incluyen:
- Coordinar la lectura de los registros de transacciones y el archivo de los archivos de registro (el software de administración de bases de datos normalmente archiva los archivos de registro fuera de línea de forma regular).
- La traducción entre los formatos de almacenamiento físico que se registran en los registros de transacciones y los formatos lógicos que normalmente esperan los usuarios de la base de datos (por ejemplo, algunos registros de transacciones guardan solo diferencias mínimas de búfer que no son directamente útiles para los consumidores de cambios).
- Manejo de cambios en el formato de los registros de transacciones entre versiones del sistema de administración de bases de datos.
- Eliminando los cambios no confirmados que la base de datos escribió en el registro de transacciones y luego revertió .
- Manejo de cambios en los metadatos de tablas en la base de datos.
Las soluciones de CDC basadas en archivos de registro de transacciones tienen distintas ventajas que incluyen:
- impacto mínimo en la base de datos (aún más si se usa el trasvase de registros para procesar los registros en un host dedicado).
- no es necesario realizar cambios programáticos en las aplicaciones que utilizan la base de datos.
- baja latencia en la adquisición de cambios.
- Integridad transaccional : el escaneo de registros puede producir un flujo de cambios que reproduce las transacciones originales en el orden en que se comprometieron. Dicho flujo de cambios incluye los cambios realizados en todas las tablas que participan en la transacción capturada.
- no es necesario cambiar el esquema de la base de datos
Factores confusos
Como ocurre a menudo en dominios complejos, la solución final a un problema de CDC puede tener que equilibrar muchas preocupaciones en competencia.
Sistemas fuente inadecuados
La captura de datos de cambios aumenta en complejidad y reduce su valor si el sistema de origen guarda los cambios de metadatos cuando los datos en sí no se modifican. Por ejemplo, algunos modelos de datos rastrean al usuario que miró por última vez pero no cambió los datos en la misma estructura que los datos. Esto genera ruido en la captura de datos modificados.
Seguimiento de la captura
En realidad, el seguimiento de los cambios depende de la fuente de datos. Si los datos se conservan en una base de datos moderna, la captura de datos modificados es una simple cuestión de permisos. Hay dos técnicas de uso común:
- Seguimiento de cambios mediante activadores de base de datos
- Leer el registro de transacciones como está escrito o poco después.
Si los datos no están en una base de datos moderna, CDC se convierte en un desafío de programación.
Empujar contra tirar
- Empujar : el proceso de origen crea una instantánea de los cambios dentro de su propio proceso y entrega filas en sentido descendente. El proceso descendente utiliza la instantánea, crea su propio subconjunto y los entrega al siguiente proceso.
- Extraer : el destino que se encuentra inmediatamente en sentido descendente desde la fuente, prepara una solicitud de datos desde la fuente. El destino descendente entrega la instantánea al siguiente destino, como en el modelo de inserción.
Alternativas
A veces, la dimensión que cambia lentamente se utiliza como método. [1]
Ver también
Referencias
- ^ Eroe, Erit (2015). 4ggg . Rty.
Ver también
enlaces externos
- Captura de datos de cambios de Equalum (CDC)
- Principales desafíos de diseño e implementación con la captura de datos modificados: por Equalum
- Tutorial en vídeo: captura de datos modificados de forma sencilla con Equalum (interfaz de usuario sin código)
- Tutorial de captura de datos modificados de Striim
- Bus de datos de LinkedIn
- griddable.io Captura de datos modificados (basada en Databus) - http://www.griddable.io
- CDC de software HVR
- Captura de datos de cambio de sintonía (CDC)
- IBM Infosphere CDC
- Tutorial sobre la configuración de CDC en Oracle 9i
- Replicación de Oracle GoldenGate
- Tutorial sobre la configuración de SQL Azure Change Data Capture
- Detalles de la instalación de CDC incluida en Microsoft Sql Server 2008 Feb '08 CTP
- Distribución de datos blandos de Gamma
- BackOffice DBMoto, replicación de datos en tiempo real y captura de datos modificados
- Debezium, plataforma de captura de datos de cambios de código abierto compatible con MySQL, PostgreSQL y otros