Esta página foi traduzida pela API Cloud Translation.

Migre do Cassandra para o Spanner

Esta página explica como migrar a sua base de dados NoSQL do Cassandra para o Spanner.

O Cassandra e o Spanner são bases de dados distribuídas em grande escala criadas para aplicações que requerem elevada escalabilidade e baixa latência. Embora ambas as bases de dados possam suportar cargas de trabalho NoSQL exigentes, o Spanner oferece funcionalidades avançadas para modelagem de dados, consultas e operações transacionais. O Spanner suporta o Cassandra Query Language (CQL).

Para mais informações sobre como o Spanner cumpre os critérios da base de dados NoSQL, consulte o artigo Spanner para cargas de trabalho não relacionais.

Restrições de migração

Para uma migração bem-sucedida do Cassandra para o ponto final do Cassandra no Spanner, reveja o artigo Spanner para utilizadores do Cassandra para saber como a arquitetura, o modelo de dados e os tipos de dados do Spanner diferem do Cassandra. Pondere cuidadosamente as diferenças funcionais entre o Spanner e o Cassandra antes de iniciar a migração.

Processo de migração

O processo de migração é dividido nos seguintes passos:

Converta o seu esquema e modelo de dados.
Configure escritas duplas para dados recebidos.
Exporte em massa os seus dados do histórico do Cassandra para o Spanner.
Valide os dados para garantir a integridade dos dados durante todo o processo de migração.
Direcione a sua aplicação para o Spanner em vez do Cassandra.
Opcional. Realize a replicação inversa do Spanner para o Cassandra.

Converta o esquema e o modelo de dados

O primeiro passo na migração dos dados do Cassandra para o Spanner é adaptar o esquema de dados do Cassandra ao esquema do Spanner, ao mesmo tempo que processa as diferenças nos tipos de dados e na modelagem.

A sintaxe de declaração de tabelas é bastante semelhante no Cassandra e no Spanner. Especifica o nome da tabela, os nomes e os tipos das colunas, bem como a chave primária que identifica exclusivamente uma linha. A principal diferença é que o Cassandra tem partições hash e faz uma distinção entre as duas partes da chave primária: a chave de partição com hash e as colunas de agrupamento ordenadas, enquanto o Spanner tem partições de intervalo. Pode considerar que a chave principal do Spanner tem apenas colunas de agrupamento, com partições mantidas automaticamente em segundo plano. Tal como o Cassandra, o Spanner suporta chaves primárias compostas.

Recomendamos os seguintes passos para converter o esquema de dados do Cassandra para o Spanner:

Reveja a vista geral do Cassandra para compreender as semelhanças e as diferenças entre os esquemas de dados do Cassandra e do Spanner, e para saber como mapear diferentes tipos de dados.
Use a ferramenta de esquema do Cassandra para o Spanner para extrair e converter o esquema de dados do Cassandra para o Spanner.
Antes de iniciar a migração de dados, certifique-se de que as tabelas do Spanner foram criadas com os esquemas de dados adequados.

Configure a migração em direto para dados recebidos

Para fazer uma migração sem tempo de inatividade do Cassandra para o Spanner, configure a migração em direto para os dados recebidos. A migração em direto foca-se em minimizar o tempo de inatividade e garantir a disponibilidade contínua da aplicação através da replicação em tempo real.

Comece com o processo de migração em direto antes da migração em massa. O diagrama seguinte mostra a vista arquitetónica de uma migração em direto.

As apps enviam escritas através de um proxy para o Spanner e o Cassandra

A arquitetura de migração em direto tem os seguintes componentes principais:

Origem: a sua base de dados Cassandra de origem.
Destino: a base de dados do Spanner para a qual está a migrar. Presume-se que já aprovisionou a sua instância do Spanner e a base de dados com um esquema compatível com o seu esquema do Cassandra (com as adaptações necessárias para o modelo de dados e as funcionalidades do Spanner).
Datastax ZDM Proxy: o ZDM Proxy é um proxy de escritas duplas criado pela DataStax para migrações de Cassandra para Cassandra. O proxy imita um cluster do Cassandra, o que permite que uma aplicação use o proxy sem alterações à aplicação. Esta ferramenta é o que a sua aplicação usa para comunicar e, internamente, usa para fazer escritas duplas nas bases de dados de origem e de destino. Embora seja normalmente usado com clusters do Cassandra como origem e destino, a nossa configuração configura-o para usar o proxy do Cassandra-Spanner (em execução como um sidecar) como destino. Isto garante que cada leitura recebida só é encaminhada para a origem e devolve a resposta da origem à aplicação. Além disso, cada gravação recebida é direcionada para a origem e o destino.
- Se as gravações na origem e no destino forem bem-sucedidas, a aplicação recebe uma mensagem de êxito.
- Se as escritas na origem falharem e as escritas no destino forem bem-sucedidas, a aplicação recebe a mensagem de falha da origem.
- Se as escritas no destino falharem e as escritas na origem forem bem-sucedidas, a aplicação recebe a mensagem de falha do destino.
- Se as escritas na origem e no destino falharem, a aplicação recebe a mensagem de falha da origem.
Cassandra-Spanner Proxy: Uma aplicação sidecar que interceta o tráfego de linguagem de consulta Cassandra (CQL) destinado ao Cassandra e traduz o mesmo em chamadas da API Spanner. Permite que as aplicações e as ferramentas interajam com o Spanner através do cliente Cassandra.
Aplicação cliente: a aplicação que lê e escreve dados no cluster Cassandra de origem.

Configuração do proxy

O primeiro passo para fazer uma migração em direto é implementar e configurar os proxies. O proxy Cassandra-Spanner é executado como um sidecar para o proxy ZDM. O proxy complementar atua como o destino das operações de escrita do proxy ZDM no Spanner.

Testes de instância única com o Docker

Pode executar uma única instância do proxy localmente ou numa VM para testes iniciais com o Docker.

Pré-requisitos

Confirme se a VM onde o proxy é executado tem conetividade de rede com a aplicação, a base de dados Cassandra de origem e a base de dados Spanner.
Instale o Docker.
Confirme se existe um ficheiro de chave da conta de serviço com as autorizações necessárias para escrever na instância e na base de dados do Spanner.
Configure a instância, a base de dados e o esquema do Spanner.
Certifique-se de que o nome da base de dados do Spanner é igual ao nome do espaço de chaves do Cassandra de origem.
Clone o repositório spanner-migration-tool.

Transfira e configure o proxy do ZDM

Aceda ao diretório sources/cassandra.
Certifique-se de que os ficheiros entrypoint.sh e Dockerfile estão no mesmo diretório que o Dockerfile.
Execute o seguinte comando para criar uma imagem local:
```
docker build -t zdm-proxy:latest .
```

Execute o proxy do ZDM

Certifique-se de que os ficheiros zdm-config.yaml e keyfiles estão presentes localmente onde o seguinte comando é executado.
Abra o ficheiro zdm-config yaml de exemplo.
Reveja a lista detalhada de flags que o ZDM aceita.

Use o seguinte comando para executar o contentor:

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

Valide a configuração do proxy

Use o comando docker logs para verificar se existem erros nos registos do proxy durante o arranque:
```
docker logs container-id
```
Execute o comando cqlsh para verificar se o proxy está configurado corretamente:
```
cqlsh VM-IP 14002
```
Substitua VM-IP pelo endereço IP da sua VM.

Configuração de produção com o Terraform:

Para um ambiente de produção, recomendamos que use os modelos do Terraform fornecidos para orquestrar a implementação do proxy Cassandra-Spanner.

Pré-requisitos

Instale o Terraform.
Confirme que a aplicação tem credenciais predefinidas com as autorizações adequadas para criar recursos.
Confirme se o ficheiro de chave de serviço tem as autorizações relevantes para escrever no Spanner. Este ficheiro é usado pelo proxy.
Configure a instância, a base de dados e o esquema do Spanner.
Confirme que o ficheiro Dockerfile, entrypoint.sh e o ficheiro de chave de serviço estão no mesmo diretório que o ficheiro main.tf.

Configure variáveis do Terraform

Certifique-se de que tem o modelo do Terraform para a implementação do proxy.
Atualize o ficheiro terraform.tfvars com as variáveis da sua configuração.

Implementação de modelos com o Terraform

O script do Terraform faz o seguinte:

Cria VMs otimizadas para contentores com base numa quantidade especificada.
Cria zdm-config.yaml ficheiros para cada VM e atribui-lhe um índice de topologia. O proxy do ZDM requer configurações com várias VMs para configurar a topologia através dos campos PROXY_TOPOLOGY_ADDRESSES e PROXY_TOPOLOGY_INDEX no ficheiro yaml de configuração.
Transfere os ficheiros relevantes para cada VM, executa remotamente o Docker Build e inicia os contentores.

Para implementar o modelo, faça o seguinte:

Use o comando terraform init para inicializar o Terraform:
```
terraform init
```
Execute o comando terraform plan para ver que alterações o Terraform planeia fazer na sua infraestrutura:
```
terraform plan -var-file="terraform.tfvars"
```
Quando os recursos estiverem em bom estado, execute o comando terraform apply:
```
terraform apply -var-file="terraform.tfvars"
```
Depois de o script do Terraform parar, execute o comando cqlsh para garantir que as VMs estão acessíveis.
```
cqlsh VM-IP 14002
```
Substitua VM-IP pelo endereço IP da sua VM.

Direcione as suas aplicações cliente para o proxy do ZDM

Modifique a configuração da aplicação cliente, definindo os pontos de contacto como as VMs que executam os proxies em vez do cluster Cassandra de origem.

Teste a sua aplicação exaustivamente. Verifique se as operações de escrita estão a ser aplicadas ao cluster Cassandra de origem e, verificando a sua base de dados Spanner, se também estão a chegar ao Spanner através do proxy Cassandra-Spanner. As leituras são publicadas a partir da origem Cassandra.

Exporte os seus dados em massa para o Spanner

A migração de dados em massa envolve a transferência de grandes volumes de dados entre bases de dados, o que requer frequentemente um planeamento e uma execução cuidadosos para minimizar o tempo de inatividade e garantir a integridade dos dados. As técnicas incluem processos de ETL (extração, transformação e carregamento), replicação direta da base de dados e ferramentas de migração especializadas, todas destinadas a mover dados de forma eficiente, preservando a respetiva estrutura e precisão.

Recomendamos que use o modelo do Dataflow SourceDB para o Spanner para migrar em massa os seus dados do Cassandra para o Spanner. O Dataflow é o serviço de extração, transformação e carregamento (ETL) distribuído que oferece uma plataforma para executar pipelines de dados para ler e processar grandes quantidades de dados em paralelo em várias máquinas. Google Cloud O modelo SourceDB To Spanner Dataflow foi concebido para fazer leituras altamente paralelizadas a partir do Cassandra, transformar os dados de origem conforme necessário e escrever no Spanner como uma base de dados de destino.

Execute os passos nas instruções de migração em massa do Cassandra para o Spanner usando o ficheiro de configuração do Cassandra.

Valide os dados para garantir a integridade

A validação de dados durante a migração da base de dados é fundamental para garantir a precisão e a integridade dos dados. Envolve a comparação de dados entre as bases de dados Cassandra de origem e Spanner de destino para identificar discrepâncias, como dados em falta, danificados ou com incompatibilidades. As técnicas gerais de validação de dados incluem somas de verificação, contagens de linhas e comparações detalhadas de dados, todas destinadas a garantir que os dados migrados são uma representação precisa dos originais.

Após a conclusão da migração de dados em massa e enquanto as gravações duplas ainda estiverem ativas, tem de validar a consistência dos dados e corrigir as discrepâncias. As diferenças entre o Cassandra e o Spanner podem ocorrer durante a fase de gravação dupla por vários motivos, incluindo:

Falhas nas gravações duplas. Uma operação de escrita pode ter êxito numa base de dados, mas falhar na outra devido a problemas de rede transitórios ou outros erros.
Transações informais (LWT). Se a sua aplicação usar operações LWT (compare and set), estas podem ter êxito numa base de dados, mas falhar na outra devido a diferenças nos conjuntos de dados.
Consultas por segundo (CPS) elevadas numa única chave principal. Em cargas de gravação muito elevadas na mesma chave de partição, a ordem dos eventos pode diferir entre a origem e o destino devido a diferentes tempos de ida e volta da rede, o que pode levar a inconsistências.
Trabalho em massa e escritas duplas em execução em paralelo: a migração em massa em execução em paralelo com escritas duplas pode causar divergência devido a várias condições de concorrência, como as seguintes:
- Linhas adicionais no Spanner: se a migração em massa for executada enquanto as escritas duplas estiverem ativas, a aplicação pode eliminar uma linha que já foi lida pela tarefa de migração em massa e escrita no destino.
- Condições de concorrência entre escritas em massa e duplas: podem existir outras condições de concorrência diversas em que a tarefa em massa lê uma linha do Cassandra e os dados da linha ficam desatualizados quando as escritas recebidas atualizam a linha no Spanner após a conclusão das escritas duplas.
- Atualizações parciais de colunas: a atualização de um subconjunto de colunas numa linha existente cria uma entrada no Spanner com outras colunas como nulas. Uma vez que as atualizações em massa não substituem as linhas existentes, isto faz com que as linhas divirjam entre o Cassandra e o Spanner.

Este passo centra-se na validação e conciliação dos dados entre as bases de dados de origem e de destino. A validação envolve a comparação da origem e do destino para identificar inconsistências, enquanto a conciliação se foca na resolução destas inconsistências para alcançar a consistência dos dados.

Compare dados entre o Cassandra e o Spanner

Recomendamos que faça validações nas contagens de linhas e no conteúdo real das linhas.

A escolha da forma de comparar os dados (contagem e correspondência de linhas) depende da tolerância da sua aplicação a inconsistências de dados e dos seus requisitos de validação exata.

Existem duas formas de validar dados:

A validação ativa é realizada enquanto as escritas duplas estão ativas. Neste cenário, os dados nas suas bases de dados continuam a ser atualizados. Pode não ser possível alcançar uma correspondência exata nas contagens de linhas ou no conteúdo das linhas entre o Cassandra e o Spanner. O objetivo é garantir que quaisquer diferenças se devem apenas à carga ativa nas bases de dados e não a outros erros. Se as discrepâncias estiverem dentro destes limites, pode prosseguir com a mudança.
A validação estática requer tempo de inatividade. Se os seus requisitos exigirem uma validação estática forte com uma garantia de consistência exata dos dados, pode ter de parar temporariamente todas as gravações em ambas as bases de dados. Em seguida, pode validar os dados e conciliar as diferenças na sua base de dados do Spanner.

Escolha o momento da validação e as ferramentas adequadas com base nos seus requisitos específicos de consistência dos dados e tempo de inatividade aceitável.

Compare o número de linhas no Cassandra e no Spanner

Um método de validação de dados consiste em comparar o número de linhas nas tabelas nas bases de dados de origem e de destino. Existem algumas formas de fazer validações de contagem:

Quando migrar com pequenos conjuntos de dados (menos de 10 milhões de linhas por tabela), pode usar este script de correspondência de contagens para contar linhas no Cassandra e no Spanner. Esta abordagem devolve contagens exatas num curto período de tempo. O tempo limite predefinido no Cassandra é de 10 segundos. Pondere aumentar o limite de tempo do pedido do controlador e o limite de tempo do lado do servidor se o script exceder o limite de tempo antes de terminar a contagem.
Quando migrar grandes conjuntos de dados (mais de 10 milhões de linhas por tabela), tenha em atenção que, embora as consultas de contagem do Spanner sejam bem dimensionadas, as consultas do Cassandra tendem a atingir o limite de tempo. Nestes casos, recomendamos que use a ferramenta DataStax Bulk Loader para obter o número de linhas das tabelas do Cassandra. Para as contagens do Spanner, a utilização da função SQL count(*) é suficiente para a maioria dos carregamentos em grande escala. Recomendamos que execute o carregador em massa para cada tabela do Cassandra e obtenha as contagens da tabela do Spanner e compare as duas. Isto pode ser feito manualmente ou através de um script.

Valide uma falta de correspondência de linhas

Recomendamos que compare as linhas das bases de dados de origem e de destino para identificar incompatibilidades entre as linhas. Existem duas formas de fazer validações de linhas. A que usa depende dos requisitos da sua aplicação:

Validar um conjunto aleatório de linhas.
Validar o conjunto de dados completo.

Valide uma amostra aleatória de linhas

A validação de um conjunto de dados completo é dispendiosa e demorada para cargas de trabalho grandes. Nestes casos, pode usar a amostragem para validar um subconjunto aleatório dos dados para verificar se existem incompatibilidades nas linhas. Uma forma de o fazer é escolher linhas aleatórias no Cassandra e obter as linhas correspondentes no Spanner e, em seguida, comparar os valores (ou o hash da linha).

As vantagens deste método são que termina mais rapidamente do que verificar um conjunto de dados completo e é simples de executar. A desvantagem é que, como se trata de um subconjunto dos dados, ainda podem existir diferenças nos dados presentes para casos extremos.

Para obter uma amostra de linhas aleatórias do Cassandra, tem de fazer o seguinte:

Gera números aleatórios no intervalo de tokens [-2^63, 2^63 - 1].
Obter linhas WHERE token(PARTITION_KEY) > GENERATED_NUMBER.

O validation.goscript de exemplo obtém linhas aleatoriamente e valida-as com linhas na base de dados do Spanner.

Valide o conjunto de dados completo

Para validar um conjunto de dados completo, obtenha todas as linhas na base de dados Cassandra de origem. Use as chaves principais para obter todas as linhas da base de dados do Spanner correspondentes. Em seguida, pode comparar as linhas para ver as diferenças. Para grandes conjuntos de dados, pode usar uma estrutura baseada em MapReduce, como o Apache Spark ou o Apache Beam, para validar de forma fiável e eficiente todo o conjunto de dados.

A vantagem desta opção é que a validação completa oferece uma maior confiança na consistência dos dados. As desvantagens são que adiciona carga de leitura no Cassandra e requer um investimento para criar ferramentas complexas para grandes conjuntos de dados. Também pode demorar muito mais tempo a concluir a validação num conjunto de dados grande.

Uma forma de o fazer é particionar os intervalos de tokens e consultar o anel do Cassandra em paralelo. Para cada linha do Cassandra, a linha do Spanner equivalente é obtida através da chave de partição. Em seguida, estas duas linhas são comparadas para verificar se existem discrepâncias. Para obter sugestões a seguir ao criar tarefas de validação, consulte o artigo Sugestões para validar o Cassandra através da correspondência de linhas.

Reconcilie inconsistências de dados ou de contagem de linhas

Consoante o requisito de consistência dos dados, pode copiar linhas do Cassandra para o Spanner para conciliar as discrepâncias identificadas durante a fase de validação. Uma forma de fazer a conciliação é estender a ferramenta usada para a validação completa do conjunto de dados e copiar a linha correta do Cassandra para a base de dados do Spanner de destino se for encontrado um desencontro. Para mais informações, consulte as Considerações de implementação.

Aponte a sua aplicação para o Spanner em vez do Cassandra

Depois de validar a precisão e a integridade dos dados após a migração, escolha uma hora para migrar a sua aplicação para apontar para o Spanner em vez do Cassandra (ou para o adaptador de proxy usado para a migração de dados em direto). Isto chama-se transição.

Para fazer a mudança, siga estes passos:

Crie uma alteração de configuração para a sua aplicação cliente que lhe permita ligar-se diretamente à sua instância do Spanner através de um dos seguintes métodos:
- Ligue o Cassandra ao adaptador do Cassandra em execução como um sidecar.
- Altere o JAR do controlador com o cliente do ponto final.
Aplique a alteração que preparou no passo anterior para direcionar a sua aplicação para o Spanner.
Configure a monitorização da sua aplicação para monitorizar erros ou problemas de desempenho. Monitorize as métricas do Spanner com o Cloud Monitoring. Para mais informações, consulte o artigo Monitorize instâncias com o Cloud Monitoring.
Após uma mudança bem-sucedida e uma operação estável, desative o proxy do ZDM e as instâncias do proxy do Cassandra-Spanner.

Faça a replicação inversa do Spanner para o Cassandra

Pode fazer a replicação inversa através do Spanner to SourceDBmodelo do Dataflow. A replicação inversa é útil quando encontra problemas imprevistos com o Spanner e precisa de reverter para a base de dados Cassandra original com a mínima interrupção do serviço.

Sugestões para validar o Cassandra através da correspondência de linhas

É lento e ineficiente executar análises completas de tabelas no Cassandra (ou em qualquer outra base de dados) com SELECT *. Para resolver este problema, divida o conjunto de dados do Cassandra em partições geríveis e processe as partições em simultâneo. Para o fazer, tem de efetuar o seguinte:

Divida o conjunto de dados em intervalos de tokens
Consultar partições em paralelo
Leia dados em cada partição
Obtenha as linhas correspondentes do Spanner
Ferramentas de validação de design para extensibilidade
Comunique e registe discrepâncias

Divida o conjunto de dados em intervalos de tokens

O Cassandra distribui os dados pelos nós com base em tokens de chave de partição. O intervalo de tokens para um cluster do Cassandra abrange de -2^63 a 2^63 - 1. Pode definir um número fixo de intervalos de tokens de tamanho igual para dividir o espaço de chaves inteiro em partições mais pequenas. Recomendamos que divida o intervalo de tokens com um parâmetro partition_size configurável que pode ajustar para processar rapidamente todo o intervalo.

Consultar partições em paralelo

Depois de definir os intervalos de tokens, pode iniciar vários processos ou threads paralelos, cada um responsável pela validação de dados num intervalo específico. Para cada intervalo, pode construir consultas CQL usando a função token na chave de partição (pk).

Uma consulta de exemplo para um determinado intervalo de tokens teria o seguinte aspeto:

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

Ao iterar os intervalos de tokens definidos e executar estas consultas em paralelo no cluster do Cassandra de origem (ou através do proxy ZDM configurado para ler a partir do Cassandra), lê os dados de forma distribuída de forma eficiente.

Ler dados em cada partição

Cada processo paralelo executa a consulta baseada no intervalo e obtém um subconjunto dos dados do Cassandra. Verifique a quantidade de dados da partição obtidos para garantir o equilíbrio entre o paralelismo e a utilização de memória.

Obtenha as linhas correspondentes do Spanner

Para cada linha obtida do Cassandra, obtenha a linha correspondente da base de dados do Spanner de destino através da chave da linha de origem.

Compare linhas para identificar incompatibilidades

Depois de ter a linha do Cassandra e a linha do Spanner correspondente (se existir), tem de comparar os respetivos campos para identificar eventuais incompatibilidades. Esta comparação deve ter em conta as potenciais diferenças de tipo de dados e as transformações aplicadas durante a migração. Recomendamos que defina critérios claros para o que constitui uma incompatibilidade com base nos requisitos da sua aplicação.

Crie ferramentas de validação para extensibilidade

Crie a sua ferramenta de validação com a possibilidade de a expandir para a conciliação. Por exemplo, pode adicionar capacidades para escrever os dados corretos de Cassandra para Spanner para as não correspondências identificadas.

Denuncie e registe as não correspondências

Recomendamos que registe quaisquer incompatibilidades identificadas com contexto suficiente para permitir a investigação e a conciliação. Isto pode incluir as chaves primárias, os campos específicos que diferem e os valores do Cassandra e do Spanner. Também pode querer agregar estatísticas sobre o número e os tipos de discrepâncias encontradas.

Ative e desative o TTL nos dados do Cassandra

Esta secção descreve como ativar e desativar o tempo de vida (TTL) nos dados do Cassandra em tabelas do Spanner. Para uma vista geral, consulte o artigo Tempo de vida (TTL).

Ative o TTL nos dados do Cassandra

Para os exemplos nesta secção, suponha que tem uma tabela com o seguinte esquema:

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

Para ativar o TTL ao nível da linha numa tabela existente, faça o seguinte:

Adicione a coluna de indicação de tempo para armazenar a indicação de tempo de validade de cada linha. Neste exemplo, a coluna tem o nome ExpiredAt, mas pode usar qualquer nome.
```
ALTER TABLE Singers ADD COLUMN ExpiredAt TIMESTAMP;
```
Adicione a política de eliminação de linhas para eliminar automaticamente linhas mais antigas do que a hora de validade. INTERVAL 0 DAY significa que as linhas são eliminadas imediatamente assim que o tempo de expiração é atingido.
```
ALTER TABLE Singers ADD ROW DELETION POLICY (OLDER_THAN(ExpiredAt, INTERVAL 0 DAY));
```

Defina cassandra_ttl_mode como row para ativar o TTL ao nível da linha.

ALTER TABLE Singers SET OPTIONS (cassandra_ttl_mode = 'row');

Opcionalmente, defina cassandra_default_ttl para configurar o valor TTL predefinido. O valor é expresso em segundos.
```
ALTER TABLE Singers SET OPTIONS (cassandra_default_ttl = 10000);
```

Desative o TTL nos dados do Cassandra