Se usó la API de Cloud Translation para traducir esta página.

Migra de Cassandra a Spanner

En esta página, se explica cómo migrar tu base de datos NoSQL de Cassandra a Spanner.

Cassandra y Spanner son bases de datos distribuidas a gran escala creadas para aplicaciones que requieren alta escalabilidad y baja latencia. Si bien ambas bases de datos pueden admitir cargas de trabajo NoSQL exigentes, Spanner proporciona funciones avanzadas para el modelado de datos, las consultas y las operaciones transaccionales. Spanner admite el lenguaje de consultas de Cassandra (CQL).

Para obtener más información sobre cómo Spanner cumple con los criterios de las bases de datos NoSQL, consulta Spanner para cargas de trabajo no relacionales.

Restricciones de migración

Para realizar una migración exitosa de Cassandra al extremo de Cassandra en Spanner, consulta Spanner para usuarios de Cassandra y descubre cómo la arquitectura, el modelo de datos y los tipos de datos de Spanner difieren de los de Cassandra. Antes de comenzar la migración, considera con atención las diferencias funcionales entre Spanner y Cassandra.

Proceso de migración

El proceso de migración se divide en los siguientes pasos:

Convierte tu esquema y modelo de datos.
Configura escrituras duales para los datos entrantes.
Exporta de forma masiva tus datos históricos de Cassandra a Spanner.
Valida los datos para garantizar su integridad durante todo el proceso de migración.
Dirige tu aplicación a Spanner en lugar de a Cassandra.
Opcional. Realiza la replicación inversa de Spanner a Cassandra.

Convierte tu esquema y modelo de datos

El primer paso para migrar tus datos de Cassandra a Spanner es adaptar el esquema de datos de Cassandra al esquema de Spanner, mientras se controlan las diferencias en los tipos de datos y el modelado.

La sintaxis de declaración de tablas es bastante similar en Cassandra y Spanner. Especificas el nombre de la tabla, los nombres y tipos de las columnas, y la clave primaria que identifica de forma única una fila. La diferencia clave es que Cassandra se particiona con hash y distingue entre las dos partes de la clave primaria: la clave de partición con hash y las columnas de agrupamiento ordenadas, mientras que Spanner se particiona por rangos. Puedes pensar en la clave primaria de Spanner como si solo tuviera columnas de agrupamiento, con particiones que se mantienen automáticamente en segundo plano. Al igual que Cassandra, Spanner admite claves primarias compuestas.

Te recomendamos que sigas estos pasos para convertir tu esquema de datos de Cassandra a Spanner:

Revisa la descripción general de Cassandra para comprender las similitudes y diferencias entre los esquemas de datos de Cassandra y Spanner, y aprender a asignar diferentes tipos de datos.
Usa la herramienta de esquema de Cassandra a Spanner para extraer y convertir tu esquema de datos de Cassandra a Spanner.
Antes de comenzar la migración de datos, asegúrate de que tus tablas de Spanner se hayan creado con los esquemas de datos adecuados.

Configura la migración en vivo para los datos entrantes

Para realizar una migración sin tiempo de inactividad de Cassandra a Spanner, configura la migración en vivo para los datos entrantes. La migración en vivo se enfoca en minimizar el tiempo de inactividad y garantizar la disponibilidad continua de la aplicación a través de la replicación en tiempo real.

Comienza con el proceso de migración en vivo antes de la migración masiva. En el siguiente diagrama, se muestra la vista arquitectónica de una migración en vivo.

Las apps envían escrituras a través de un proxy tanto a Spanner como a Cassandra.

La arquitectura de migración en vivo tiene los siguientes componentes clave:

Origen: Es tu base de datos de Cassandra de origen.
Destino: Es la base de datos de Spanner a la que migrarás. Se supone que ya aprovisionaste tu instancia de Spanner y tu base de datos con un esquema compatible con tu esquema de Cassandra (con las adaptaciones necesarias para el modelo de datos y las funciones de Spanner).
Proxy de ZDM de DataStax: El proxy de ZDM es un proxy de escritura doble compilado por DataStax para migraciones de Cassandra a Cassandra. El proxy simula un clúster de Cassandra, lo que permite que una aplicación lo use sin necesidad de realizar cambios en ella. Esta herramienta es con la que se comunica tu aplicación y la que usa internamente para realizar escrituras dobles en las bases de datos de origen y destino. Si bien se suele usar con clústeres de Cassandra como origen y destino, nuestra configuración lo establece para que use el proxy de Cassandra-Spanner (que se ejecuta como un sidecar) como destino. Esto garantiza que cada lectura entrante solo se reenvíe al origen y que la respuesta del origen se devuelva a la aplicación. Además, cada escritura entrante se dirige tanto al origen como al destino.
- Si las escrituras en el origen y el destino se realizan correctamente, la aplicación recibe un mensaje de éxito.
- Si las escrituras en el origen fallan y las escrituras en el destino se realizan correctamente, la aplicación recibe el mensaje de error del origen.
- Si fallan las escrituras en el destino y se realizan correctamente en el origen, la aplicación recibe el mensaje de error del destino.
- Si fallan las escrituras en el origen y el destino, la aplicación recibe el mensaje de error del origen.
Proxy de Cassandra-Spanner: Es una aplicación complementaria que intercepta el tráfico del lenguaje de consultas de Cassandra (CQL) destinado a Cassandra y lo traduce en llamadas a la API de Spanner. Permite que las aplicaciones y las herramientas interactúen con Spanner a través del cliente de Cassandra.
Aplicación cliente: Es la aplicación que lee y escribe datos en el clúster de Cassandra de origen.

Configuración del proxy

El primer paso para realizar una migración en vivo es implementar y configurar los proxies. El proxy de Cassandra-Spanner se ejecuta como un sidecar del proxy de ZDM. El proxy de sidecar actúa como destino para las operaciones de escritura del proxy de ZDM en Spanner.

Pruebas de instancias únicas con Docker

Puedes ejecutar una sola instancia del proxy de forma local o en una VM para realizar pruebas iniciales con Docker.

Requisitos previos

Confirma que la VM en la que se ejecuta el proxy tenga conectividad de red con la aplicación, la base de datos de Cassandra de origen y la base de datos de Spanner.
Instala Docker.
Confirma que haya un archivo de clave de cuenta de servicio con los permisos necesarios para escribir en tu instancia y base de datos de Spanner.
Configura tu instancia, base de datos y esquema de Spanner.
Asegúrate de que el nombre de la base de datos de Spanner sea el mismo que el nombre del espacio de claves de Cassandra de origen.
Clona el repositorio spanner-migration-tool.

Descarga y configura el proxy de ZDM

Ve al directorio sources/cassandra.
Asegúrate de que los archivos entrypoint.sh y Dockerfile estén en el mismo directorio que el Dockerfile.
Ejecuta el siguiente comando para compilar una imagen local:
```
docker build -t zdm-proxy:latest .
```

Ejecuta el proxy de ZDM

Asegúrate de que zdm-config.yaml y keyfiles estén presentes de forma local donde se ejecuta el siguiente comando.
Abre el archivo de muestra zdm-config.yaml.
Revisa la lista de marcas detallada que acepta ZDM.

Usa el siguiente comando para ejecutar el contenedor:

sudo docker run --restart always  -d -p 14002:14002 \
-v zdm-config-file-path:/zdm-config.yaml  \
-v local_keyfile:/var/run/secret/keys.json \
-e SPANNER_PROJECT=SPANNER_PROJECT_ID \
-e SPANNER_INSTANCE=SPANNER_INSTANCE_ID \
-e SPANNER_DATABASE=SPANNER_DATABASE_ID   \
-e GOOGLE_APPLICATION_CREDENTIALS="/var/run/secret/keys.json" \
-e ZDM_CONFIG=/zdm-config.yaml \
zdm-proxy:latest

Verifica la configuración del proxy

Usa el comando docker logs para verificar si hay errores en los registros del proxy durante el inicio:
```
docker logs container-id
```
Ejecuta el comando cqlsh para verificar que el proxy esté configurado correctamente:
```
cqlsh VM-IP 14002
```
Reemplaza VM-IP por la dirección IP de tu VM.

Configuración de producción con Terraform:

Para un entorno de producción, recomendamos usar las plantillas de Terraform proporcionadas para organizar la implementación del proxy de Cassandra-Spanner.

Requisitos previos

Instala Terraform.
Confirma que la aplicación tenga credenciales predeterminadas con los permisos adecuados para crear recursos.
Confirma que el archivo de clave de servicio tenga los permisos pertinentes para escribir en Spanner. El proxy usa este archivo.
Configura tu instancia, base de datos y esquema de Spanner.
Confirma que el Dockerfile, entrypoint.sh y el archivo de clave de servicio se encuentren en el mismo directorio que el archivo main.tf.

Configura las variables de Terraform

Asegúrate de tener la plantilla de Terraform para la implementación del proxy.
Actualiza el archivo terraform.tfvars con las variables de tu configuración.

Implementación de plantillas con Terraform

La secuencia de comandos de Terraform hace lo siguiente:

Crea VMs optimizadas para contenedores según un recuento especificado.
Crea archivos zdm-config.yaml para cada VM y le asigna un índice de topología. El proxy de ZDM requiere configuraciones de varias VM para configurar la topología con los campos PROXY_TOPOLOGY_ADDRESSES y PROXY_TOPOLOGY_INDEX en el archivo de configuración yaml.
Transfiere los archivos pertinentes a cada VM, ejecuta Docker Build de forma remota y lanza los contenedores.

Para implementar la plantilla, haz lo siguiente:

Usa el comando terraform init para inicializar Terraform:
```
terraform init
```
Ejecuta el comando terraform plan para ver qué cambios planea realizar Terraform en tu infraestructura:
```
terraform plan -var-file="terraform.tfvars"
```
Cuando los recursos se vean bien, ejecuta el comando terraform apply:
```
terraform apply -var-file="terraform.tfvars"
```
Después de que se detenga la secuencia de comandos de Terraform, ejecuta el comando cqlsh para asegurarte de que se pueda acceder a las VMs.
```
cqlsh VM-IP 14002
```
Reemplaza VM-IP por la dirección IP de tu VM.

Apunta tus aplicaciones cliente al proxy de ZDM

Modifica la configuración de tu aplicación cliente y establece los puntos de contacto como las VMs que ejecutan los proxies en lugar de tu clúster de Cassandra de origen.

Prueba tu aplicación en detalle. Verifica que las operaciones de escritura se apliquen tanto al clúster de Cassandra de origen como a tu base de datos de Spanner. Para ello, comprueba que también lleguen a Spanner a través del proxy de Cassandra-Spanner. Las lecturas se realizan desde el origen de Cassandra.

Exporta tus datos de forma masiva a Spanner

La migración masiva de datos implica transferir grandes volúmenes de datos entre bases de datos, lo que a menudo requiere una planificación y ejecución cuidadosas para minimizar el tiempo de inactividad y garantizar la integridad de los datos. Las técnicas incluyen procesos de ETL (extracción, transformación y carga), replicación directa de bases de datos y herramientas de migración especializadas, todo ello con el objetivo de transferir datos de manera eficiente y, al mismo tiempo, preservar su estructura y precisión.

Recomendamos usar la plantilla de Dataflow SourceDB To Spanner de Spanner para migrar de forma masiva tus datos de Cassandra a Spanner. Dataflow es el servicio de extracción, transformación y carga (ETL) distribuido de Google Cloud que proporciona una plataforma para ejecutar canalizaciones de datos para leer y procesar grandes cantidades de datos en paralelo en varias máquinas. La plantilla de Dataflow de SourceDB a Spanner está diseñada para realizar lecturas altamente paralelizadas desde Cassandra, transformar los datos de origen según sea necesario y escribir en Spanner como base de datos de destino.

Sigue los pasos que se indican en las instrucciones de Migración masiva de Cassandra a Spanner con el archivo de configuración de Cassandra.

Validar los datos para garantizar su integridad

La validación de datos durante la migración de bases de datos es fundamental para garantizar la exactitud y la integridad de los datos. Consiste en comparar los datos entre las bases de datos de Cassandra de origen y Spanner de destino para identificar discrepancias, como datos faltantes, dañados o que no coinciden. Las técnicas generales de validación de datos incluyen sumas de verificación, recuentos de filas y comparaciones detalladas de datos, todo con el objetivo de garantizar que los datos migrados sean una representación precisa de los originales.

Una vez que se complete la migración masiva de datos y mientras las escrituras duales sigan activas, deberás validar la coherencia de los datos y corregir las discrepancias. Las diferencias entre Cassandra y Spanner pueden ocurrir durante la fase de escritura doble por varios motivos, incluidos los siguientes:

Error en las escrituras duales. Una operación de escritura puede tener éxito en una base de datos, pero fallar en la otra debido a problemas de red transitorios o a otros errores.
Transacciones ligeras (LWT). Si tu aplicación usa operaciones de LWT (comparar y establecer), es posible que estas se realicen correctamente en una base de datos, pero no en la otra debido a diferencias en los conjuntos de datos.
Alta cantidad de consultas por segundo (QPS) en una sola clave principal. Con cargas de escritura muy altas en la misma clave de partición, el orden de los eventos puede diferir entre el origen y el destino debido a los diferentes tiempos de ida y vuelta de la red, lo que podría generar incoherencias.
Trabajo masivo y escrituras dobles que se ejecutan en paralelo: La migración masiva que se ejecuta en paralelo con las escrituras dobles puede causar divergencias debido a varias condiciones de carrera, como las siguientes:
- Filas adicionales en Spanner: Si la migración masiva se ejecuta mientras las escrituras duales están activas, es posible que la aplicación borre una fila que el trabajo de migración masiva ya leyó y escribió en el destino.
- Condiciones de carrera entre escrituras masivas y dobles: Puede haber otras condiciones de carrera diversas en las que el trabajo masivo lee una fila de Cassandra y los datos de la fila quedan obsoletos cuando las escrituras entrantes actualizan la fila en Spanner después de que finalizan las escrituras dobles.
- Actualizaciones parciales de columnas: Cuando se actualiza un subconjunto de columnas en una fila existente, se crea una entrada en Spanner con otras columnas como nulas. Dado que las actualizaciones masivas no reemplazan las filas existentes, esto hace que las filas difieran entre Cassandra y Spanner.

Este paso se enfoca en validar y conciliar los datos entre las bases de datos de origen y destino. La validación implica comparar el origen y el destino para identificar incoherencias, mientras que la conciliación se enfoca en resolver estas incoherencias para lograr la coherencia de los datos.

Compara datos entre Cassandra y Spanner

Te recomendamos que realices validaciones en los recuentos de filas y en el contenido real de las filas.

Elegir cómo comparar los datos (tanto el recuento como la coincidencia de filas) depende de la tolerancia de tu aplicación a las incoherencias de los datos y de tus requisitos para la validación exacta.

Existen dos formas de validar los datos:

La validación activa se realiza mientras las escrituras dobles están activas. En esta situación, los datos de tus bases de datos se siguen actualizando. Es posible que no se pueda lograr una coincidencia exacta en el recuento o el contenido de las filas entre Cassandra y Spanner. El objetivo es garantizar que las diferencias se deban solo a la carga activa en las bases de datos y no a otros errores. Si las discrepancias se encuentran dentro de estos límites, puedes continuar con el cambio.
La validación estática requiere tiempo de inactividad. Si tus requisitos exigen una validación estática y sólida con una garantía de coherencia exacta de los datos, es posible que debas detener temporalmente todas las escrituras en ambas bases de datos. Luego, puedes validar los datos y conciliar las diferencias en tu base de datos de Spanner.

Elige el momento de validación y las herramientas adecuadas según tus requisitos específicos de coherencia de los datos y tiempo de inactividad aceptable.

Compara la cantidad de filas en Cassandra y Spanner

Un método de validación de datos consiste en comparar la cantidad de filas en las tablas de las bases de datos de origen y destino. Existen varias formas de realizar validaciones de recuento:

Cuando migres con conjuntos de datos pequeños (menos de 10 millones de filas por tabla), puedes usar este script de coincidencia de recuentos para contar las filas en Cassandra y Spanner. Este enfoque devuelve recuentos exactos en poco tiempo. El tiempo de espera predeterminado en Cassandra es de 10 segundos. Considera aumentar el tiempo de espera de la solicitud del controlador y el tiempo de espera del servidor si el script se agota antes de finalizar el recuento.
Cuando migres conjuntos de datos grandes (más de 10 millones de filas por tabla), ten en cuenta que, si bien las consultas de recuento de Spanner se ajustan bien, las consultas de Cassandra suelen agotar el tiempo de espera. En estos casos, recomendamos usar la herramienta DataStax Bulk Loader para obtener filas de recuento de las tablas de Cassandra. Para los recuentos de Spanner, usar la función count(*) de SQL es suficiente para la mayoría de las cargas a gran escala. Te recomendamos que ejecutes el cargador masivo para cada tabla de Cassandra, recuperes los recuentos de la tabla de Spanner y compares ambos. Esto se puede hacer de forma manual o con una secuencia de comandos.

Valida una discrepancia de filas

Te recomendamos que compares las filas de las bases de datos de origen y destino para identificar las discrepancias entre ellas. Existen dos formas de realizar validaciones de filas. La que uses dependerá de los requisitos de tu aplicación:

Valida un conjunto aleatorio de filas.
Valida todo el conjunto de datos.

Valida una muestra aleatoria de filas

Validar un conjunto de datos completo es costoso y lleva mucho tiempo para las cargas de trabajo grandes. En estos casos, puedes usar el muestreo para validar un subconjunto aleatorio de los datos y verificar si hay discrepancias en las filas. Una forma de hacerlo es elegir filas aleatorias en Cassandra y recuperar las filas correspondientes en Spanner, y, luego, comparar los valores (o el hash de la fila).

Las ventajas de este método son que terminas más rápido que si revisaras un conjunto de datos completo y que es sencillo de ejecutar. La desventaja es que, como se trata de un subconjunto de los datos, es posible que aún haya diferencias en los datos presentes para los casos extremos.

Para tomar muestras de filas aleatorias de Cassandra, debes hacer lo siguiente:

Genera números aleatorios en el rango de tokens [-2^63, 2^63 - 1].
Recupera filas WHERE token(PARTITION_KEY) > GENERATED_NUMBER.

El validation.go sample script recupera filas de forma aleatoria y las valida con las filas de la base de datos de Spanner.

Valida todo el conjunto de datos

Para validar un conjunto de datos completo, recupera todas las filas de la base de datos de Cassandra de origen. Usa las claves primarias para recuperar todas las filas correspondientes de la base de datos de Spanner. Luego, puedes comparar las filas para ver las diferencias. Para los conjuntos de datos grandes, puedes usar un framework basado en MapReduce, como Apache Spark o Apache Beam, para validar todo el conjunto de datos de manera confiable y eficiente.

La ventaja de esto es que la validación completa proporciona una mayor confianza en la coherencia de los datos. Las desventajas son que agrega carga de lectura en Cassandra y requiere una inversión para crear herramientas complejas para conjuntos de datos grandes. También es posible que se tarde mucho más en finalizar la validación en un conjunto de datos grande.

Una forma de hacerlo es particionar los rangos de tokens y consultar el anillo de Cassandra en paralelo. Para cada fila de Cassandra, se recupera la fila de Spanner equivalente con la clave de partición. Luego, se comparan estas dos filas para detectar discrepancias. Para obtener sugerencias que debes seguir cuando compiles trabajos de validación, consulta Sugerencias para validar Cassandra con la coincidencia de filas.

Cómo conciliar las incoherencias en los datos o el recuento de filas

Según el requisito de coherencia de los datos, puedes copiar filas de Cassandra a Spanner para conciliar las discrepancias identificadas durante la fase de validación. Una forma de realizar la conciliación es extender la herramienta que se usa para la validación completa del conjunto de datos y copiar la fila correcta de Cassandra a la base de datos de Spanner de destino si se encuentra una discrepancia. Para obtener más información, consulta Consideraciones sobre la implementación.

Dirige tu aplicación a Spanner en lugar de Cassandra

Después de validar la precisión y la integridad de tus datos posteriores a la migración, elige un momento para migrar tu aplicación de modo que apunte a Spanner en lugar de Cassandra (o al adaptador de proxy que se usa para la migración de datos activos). Esto se llama corte.

Para realizar la transición, sigue estos pasos:

Crea un cambio de configuración para tu aplicación cliente que le permita conectarse directamente a tu instancia de Spanner con uno de los siguientes métodos:
- Conecta Cassandra al adaptador de Cassandra que se ejecuta como un proceso secundario.
- Cambia el JAR del controlador por el cliente del extremo.
Aplica el cambio que preparaste en el paso anterior para que tu aplicación apunte a Spanner.
Configura la supervisión de tu aplicación para detectar errores o problemas de rendimiento. Supervisa las métricas de Spanner con Cloud Monitoring. Para obtener más información, consulta Supervisa instancias con Cloud Monitoring.
Después de una migración exitosa y una operación estable, retira las instancias del proxy de ZDM y del proxy de Cassandra-Spanner.

Realiza la replicación inversa de Spanner a Cassandra

Puedes realizar la replicación inversa con la plantilla de Dataflow Spanner to SourceDB. La replicación inversa es útil cuando surgen problemas imprevistos con Spanner y necesitas volver a la base de datos original de Cassandra con la menor interrupción posible del servicio.

Sugerencias para validar Cassandra con la coincidencia de filas

Es lento e ineficiente realizar análisis de tablas completos en Cassandra (o cualquier otra base de datos) con SELECT *. Para resolver este problema, divide el conjunto de datos de Cassandra en particiones manejables y procesa las particiones de forma simultánea. Para ello, sigue estos pasos:

Divide el conjunto de datos en rangos de tokens
Consulta particiones en paralelo
Leer datos dentro de cada partición
Recupera las filas correspondientes de Spanner
Herramientas de validación de diseño para la extensibilidad
Cómo registrar y denunciar discrepancias

Divide el conjunto de datos en rangos de tokens

Cassandra distribuye los datos entre los nodos según los tokens de la clave de partición. El rango de tokens de un clúster de Cassandra abarca desde -2^63 hasta 2^63 - 1. Puedes definir una cantidad fija de rangos de tokens del mismo tamaño para dividir todo el espacio de claves en particiones más pequeñas. Te recomendamos que dividas el rango de tokens con un parámetro partition_size configurable que puedas ajustar para procesar rápidamente todo el rango.

Consulta particiones en paralelo

Después de definir los rangos de tokens, puedes iniciar varios procesos o subprocesos paralelos, cada uno responsable de validar los datos dentro de un rango específico. Para cada rango, puedes crear consultas en CQL con la función token en tu clave de partición (pk).

Una consulta de ejemplo para un rango de tokens determinado se vería de la siguiente manera:

SELECT *
FROM your_keyspace.your_table
WHERE token(pk) >= partition_min_token AND token(pk) <= partition_max_token;

Si iteras a través de los rangos de tokens definidos y ejecutas estas consultas en paralelo en tu clúster de Cassandra de origen (o a través del proxy de ZDM configurado para leer desde Cassandra), podrás leer datos de manera eficiente y distribuida.

Leer datos dentro de cada partición

Cada proceso paralelo ejecuta la consulta basada en rangos y recupera un subconjunto de los datos de Cassandra. Verifica la cantidad de datos recuperados por partición para garantizar el equilibrio entre el paralelismo y el uso de memoria.

Recupera las filas correspondientes de Spanner

Para cada fila recuperada de Cassandra, recupera la fila correspondiente de tu base de datos de Spanner de destino con la clave de fila de origen.

Compara filas para identificar discrepancias

Después de obtener la fila de Cassandra y la fila de Spanner correspondiente (si existe), debes comparar sus campos para identificar cualquier discrepancia. Esta comparación debe tener en cuenta las posibles diferencias en los tipos de datos y las transformaciones que se apliquen durante la migración. Te recomendamos que definas criterios claros sobre lo que constituye una falta de coincidencia según los requisitos de tu aplicación.

Herramientas de validación de diseño para la extensibilidad

Diseña tu herramienta de validación con la posibilidad de extenderla para la reconciliación. Por ejemplo, puedes agregar capacidades para escribir los datos correctos de Cassandra en Spanner para las discrepancias identificadas.

Cómo informar y registrar las discrepancias

Te recomendamos que registres cualquier discrepancia identificada con el contexto suficiente para permitir la investigación y la conciliación. Esto puede incluir las claves primarias, los campos específicos que difieren y los valores de Cassandra y Spanner. También puedes agregar estadísticas sobre la cantidad y los tipos de discrepancias encontradas.

Cómo habilitar y deshabilitar el TTL en los datos de Cassandra

En esta sección, se describe cómo habilitar e inhabilitar el tiempo de actividad (TTL) en los datos de Cassandra en las tablas de Spanner. Para obtener una descripción general, consulta Tiempo de actividad (TTL).

Habilita el TTL en los datos de Cassandra

Para los ejemplos de esta sección, supón que tienes una tabla con el siguiente esquema:

CREATE TABLE Singers (
  SingerId INT64 OPTIONS (cassandra_type = 'bigint'),
  AlbumId INT64 OPTIONS (cassandra_type = 'int'),
) PRIMARY KEY (SingerId);

Para habilitar el TTL a nivel de las filas en una tabla existente, haz lo siguiente:

Agrega la columna de marca de tiempo para almacenar la marca de tiempo de vencimiento de cada fila. En este ejemplo, la columna se llama ExpiredAt, pero puedes usar cualquier nombre.
```
ALTER TABLE Singers ADD COLUMN ExpiredAt TIMESTAMP;
```
Agrega la política de eliminación de filas para borrar automáticamente las filas anteriores a la hora de vencimiento. INTERVAL 0 DAY significa que las filas se borran inmediatamente cuando se alcanza la fecha y hora de vencimiento.
```
ALTER TABLE Singers ADD ROW DELETION POLICY (OLDER_THAN(ExpiredAt, INTERVAL 0 DAY));
```
Establece cassandra_ttl_mode en row para habilitar el TTL a nivel de la fila.
```
ALTER TABLE Singers SET OPTIONS (cassandra_ttl_mode = 'row');
```
De manera opcional, establece cassandra_default_ttl para configurar el valor de TTL predeterminado. El valor está en segundos.
```
ALTER TABLE Singers SET OPTIONS (cassandra_default_ttl = 10000);
```

Inhabilita el TTL en los datos de Cassandra