Acerca de los flujos de cambios

Un flujo de cambio detecta y transmite los cambios de datos de una base de datos de Cloud Spanner, que se insertan, se actualizan y se borran casi en tiempo real.

En esta página, se ofrece una descripción general de alto nivel sobre los flujos de cambio de Spanner: qué hacen y cómo funcionan. Para aprender a crear y administrar transmisiones de cambios en tu base de datos y conectarlas a otros servicios, sigue los vínculos que aparecen en Pasos siguientes.

Propósito de los flujos de cambio

Las transmisiones de cambios proporcionan una forma flexible y escalable de transmitir cambios de datos a otros servicios. Los casos de uso comunes incluyen los siguientes:

  • Replicar los cambios de datos en un almacén de datos, como BigQuery, para fines de estadísticas

  • Activar la lógica de la aplicación según los cambios de datos enviados a una cola de mensajes, como Pub/Sub

  • Almacenar cambios de datos en Cloud Storage para fines de cumplimiento o archivo

Cambiar la configuración de la transmisión

Puede agregar flujos de cambio a cualquier base de datos de dialecto SQL estándar de Google.

Spanner trata a las transmisiones de cambio como objetos de esquema, al igual que los índices y las tablas. Por lo tanto, creas, modificas y borras transmisiones de cambio con declaraciones DDL, y puedes ver transmisiones de cambios de una base de datos como otros objetos de esquema administrados por DDL.

Puedes configurar un flujo de cambios para observar los cambios en los datos en una base de datos completa o limitar su alcance a tablas y columnas específicas. Una base de datos puede tener varias transmisiones de cambios, y una tabla o columna en particular puede tener varias transmisiones que la miren, dentro de los límites correspondientes.

Ejecutar el DDL que crea un flujo de cambios inicia una operación de larga duración. Cuando se completa, el nuevo flujo de cambio comienza de inmediato a observar las tablas y columnas que se le asignaron.

Observación de tablas y columnas de manera implícita

Cambia las transmisiones que ven una tabla completa para ver de forma implícita todas las columnas de esa tabla, incluso cuando se actualiza esa definición. Por ejemplo, cuando agregas columnas nuevas a esa tabla, el flujo de cambios comienza a mirar esas columnas nuevas automáticamente, sin requerir ninguna modificación en la configuración de ese flujo de cambio. Del mismo modo, el flujo de cambios deja de observar automáticamente cualquier columna que se descarte de esa tabla.

Las transmisiones de cambios en la base de datos completa funcionan de la misma manera. Observan de forma implícita todas las columnas de cada tabla, observan de forma automática las tablas o columnas que se agregan después de crear el flujo de cambios y dejan de ver cualquier tabla o columna descartada.

Observe explícitamente las tablas y las columnas

Si configuras un flujo de cambios para que solo se observen columnas particulares en una tabla y, luego, agregas columnas a esa tabla, el flujo de cambios no comenzará a ver esas columnas, a menos que vuelvas a configurar ese flujo de cambios para hacerlo.

El esquema de la base de datos trata los flujos de cambio como objetos dependientes de cualquier columna o tabla que observen de forma explícita. Antes de que puedas descartar cualquiera de esas columnas o tablas, debes quitarlas de forma manual de la configuración de cualquier flujo de cambio que las esté viendo de forma explícita.

Tipos de cambios en los datos que miran las transmisiones

Los cambios en los datos que realiza un flujo de cambios incluyen todas las inserciones, actualizaciones y eliminaciones realizadas en las tablas y columnas que ven. Estos cambios pueden provenir de las siguientes personas:

Las transmisiones de cambios pueden observar los cambios en los datos solo en las columnas y tablas que crea el usuario. No ven columnas generadas, índices, vistas, otras transmisiones de cambios ni tablas del sistema como el esquema de información o las tablas de estadísticas.

Además, las transmisiones de cambios no ven los cambios del esquema ni los cambios en los datos que se generan directamente a partir de los cambios del esquema. Por ejemplo, un flujo de cambios que mira una base de datos completa no consideraría tratar una tabla como un cambio de datos, aunque esta acción quite todos los datos de esa tabla de la base de datos.

Cómo Spanner escribe y almacena transmisiones de cambios

Cada vez que Spanner detecta un cambio de datos en una columna que ve un flujo de cambios, escribe un registro de cambio de datos en su almacenamiento interno. Lo hace de forma síncrona con ese cambio de datos, dentro de la misma transacción. Spanner ubica juntas ambas operaciones de escritura para que el mismo servidor las procese, lo que minimiza el procesamiento de escrituras.

Contenido de un registro de cambios de datos

Todos los registros de cambios de datos escritos por un flujo de cambios incluyen la siguiente información sobre el cambio de datos:

  • El nombre de la tabla afectada

  • Los nombres, los valores y los tipos de datos de las claves primarias que identifican la fila modificada

  • Los nombres y tipos de datos de las columnas modificadas de la fila

  • Los valores antiguos de las columnas modificadas de la fila (para actualizaciones y eliminaciones)

  • Los valores nuevos de las columnas modificadas de la fila (para actualizaciones e inserciones)

  • El tipo de modificación (insertar, actualizar o borrar)

  • La marca de tiempo de confirmación

  • El ID de transacción

  • El número de secuencia de registro

  • Tipo de captura de valor del registro de cambios de datos: siempre OLD_AND_NEW_VALUES

Para ver todos los valores de una fila en el momento en que se produjo un cambio, realiza una lectura inactiva de esa fila, según la marca de tiempo de confirmación del registro de cambios. La plantilla de flujo de transmisión de BigQuery a BigQuery proporciona un ejemplo de cómo incluir este comportamiento en una canalización de procesamiento de datos.

Para obtener más información sobre la estructura de los registros de cambios de datos, consulte Registros de cambios de datos.

Retención de datos

Una transmisión de cambios conserva sus registros de cambios de datos durante un período entre uno y siete días. Puedes usar DDL para especificar un límite de retención de datos que no sea el predeterminado de un día cuando se crea inicialmente un flujo de cambios, o ajustarlo en cualquier momento. Ten en cuenta que, si reduces el límite de retención de datos de un flujo de cambios, todos los datos del historial de cambios anteriores al nuevo límite dejarán de estar disponibles de forma permanente y permanente para los lectores de ese flujo de cambios.

Este período de retención de datos presenta una compensación; un período de retención más largo genera más demanda de almacenamiento en la base de datos de la transmisión.

Cómo leer transmisiones de cambios

Spanner ofrece dos maneras de leer los datos de una transmisión de cambios:

  • A través de Dataflow, con el conector de SpannerIO de Apache Beam. Esta es nuestra solución recomendada para la mayoría de las aplicaciones de transmisión de cambios. Google también proporciona plantillas de Dataflow para casos de uso comunes.

  • Directamente, mediante la API de Spanner. Esto elimina la abstracción y las capacidades de las canalizaciones de Dataflow por máxima velocidad y flexibilidad.

Usar Dataflow

Utilice el conector de SpannerIO de Apache Beam para compilar canalizaciones de Dataflow que lean desde transmisiones de cambios. Después de configurar el conector con los detalles de un flujo de cambios en particular, se generan automáticamente registros de cambios de datos nuevos en un solo conjunto de datos de PCollection no delimitado, listo para su procesamiento posterior mediante transformaciones posteriores en la canalización de Dataflow.

Google también proporciona plantillas que te permiten compilar con rapidez canalizaciones de Dataflow para casos de uso de transmisión de cambios comunes, que incluyen enviar todos los cambios de datos de una transmisión a un conjunto de datos de BigQuery o copiarlos a un bucket de Cloud Storage.

Para obtener una descripción general más detallada de cómo funcionan las transmisiones de cambios y Dataflow, consulta Compila conexiones de cambio de transmisión con Dataflow.

Usar la API

Como alternativa al uso de Dataflow para compilar canalizaciones de transmisión de cambios, puede escribir el código que usa la API de Spanner para leer los registros de una transmisión de cambios directamente. Esto te permite leer registros de cambio de datos de la misma manera que lo hace el conector de PannerIO, lo que intercambia la abstracción que proporciona a cambio de las latencias más bajas posibles cuando lee los datos de transmisión de cambios.

Para obtener más información, consulta Consulta transmisiones de cambios. Para obtener una explicación más detallada sobre cómo consultar transmisiones de cambios y cómo interpretar los registros que se muestran, consulta Cambia particiones, registros y consultas.

Límites

Existen varios límites para las transmisiones de cambios, incluida la cantidad máxima de transmisiones de cambios que puede tener una base de datos y la cantidad máxima de transmisiones que pueden mirar una sola columna. Para obtener una lista completa, consulta Cambia los límites de las transmisiones.

Permisos

Las transmisiones de cambios usan un par de permisos de IAM estándar de Spanner:

  • Crear, actualizar o descartar transmisiones de cambios requiere spanner.databases.updateDdl.

  • Para leer los datos de una transmisión de cambios, se necesita spanner.databases.select.

Si se usa el conector de SpannerIO, el propietario del trabajo de Dataflow que lee datos de transmisión de cambios requiere permisos de IAM adicionales, ya sea en la base de datos de tu aplicación o en una base de datos de metadatos independiente. Consulta Crea una base de datos de metadatos.

Prácticas recomendadas

Compare las transmisiones de cambios nuevos y cambie el tamaño si es necesario

Antes de agregar transmisiones de cambios nuevas a tu instancia de producción, considera realizar comparativas de una carga de trabajo realista en una instancia de etapa de pruebas con las transmisiones de cambios habilitadas. Esto te permite determinar si necesitas agregar nodos a tu instancia para aumentar sus capacidades de procesamiento y almacenamiento.

Ejecuta estas pruebas hasta que se estabilicen las métricas de CPU y almacenamiento. El uso de CPU de la instancia debe mantenerse por debajo de los valores máximos recomendados y el uso del almacenamiento no debe superar el límite de almacenamiento de la instancia.

Use diferentes regiones para balancear las cargas

Cuando uses transmisiones de cambios en una instancia multirregional, considera ejecutar sus canalizaciones de procesamiento en una región diferente a la región líder predeterminada. Esto ayuda a distribuir la carga de transmisión entre réplicas no líderes. Sin embargo, si necesitas priorizar la demora de transmisión más baja posible sobre el balanceo de cargas, ejecuta la carga de transmisión en la región líder.

¿Qué sigue?