As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Carregando dados históricos durante uma migração on-line
Depois de implementar gravações duplas para garantir que novos dados sejam gravados nos dois armazenamentos de dados em tempo real, a próxima etapa do plano de migração é avaliar quantos dados históricos você precisa copiar ou carregar em massa do Cassandra para o Amazon Keyspaces. Isso garante que tanto novos dados quanto dados históricos estejam disponíveis no novo banco de dados do Amazon Keyspaces antes de você migrar o aplicativo.
Dependendo dos requisitos de retenção de dados, por exemplo, quantos dados históricos você precisa preservar com base nas políticas da sua organização, você pode considerar uma das duas opções a seguir.
Upload em massa de dados históricos — A migração de dados históricos de sua implantação atual do Cassandra para o Amazon Keyspaces pode ser realizada por meio de várias técnicas, por exemplo, usando AWS Glue ou scripts personalizados para extrair, transformar e carregar (ETL) os dados. Para obter mais informações sobre o uso AWS Glue para fazer upload de dados históricos, consulteProcesso de migração off-line: Apache Cassandra para Amazon Keyspaces.
Ao planejar o upload em massa de dados históricos, você precisa considerar como resolver conflitos que podem ocorrer quando novas gravações estão tentando atualizar os mesmos dados que estão sendo carregados. Espera-se que o upload em massa seja eventualmente consistente, o que significa que os dados chegarão a todos os nós eventualmente.
Se uma atualização dos mesmos dados ocorrer ao mesmo tempo devido a uma nova gravação, você deve garantir que ela não seja substituída pelo upload de dados históricos. Para garantir que você preserve as atualizações mais recentes de seus dados mesmo durante a importação em massa, você deve adicionar a resolução de conflitos nos scripts de upload em massa ou na lógica do aplicativo para gravações duplas.
Por exemplo, você pode usar Transações leves (LWT) para comparar e definir operações. Para fazer isso, você pode adicionar um campo adicional ao seu modelo de dados que represente a hora da modificação ou o estado.
Além disso, o Amazon Keyspaces oferece suporte à função de timestamp do Cassandra
WRITETIME. Você pode usar os timestamps do lado do cliente do Amazon Keyspaces para preservar os timestamps do banco de dados de origem e implementar a resolução de conflitos. last-writer-wins Para obter mais informações, consulte Carimbos de data/hora do lado do cliente no Amazon Keyspaces.Usando Time-to-Live (TTL) — Para períodos de retenção de dados menores que 30, 60 ou 90 dias, você pode usar TTL no Cassandra e no Amazon Keyspaces durante a migração para evitar o upload de dados históricos desnecessários para o Amazon Keyspaces. TTLpermite que você defina um período após o qual os dados são removidos automaticamente do banco de dados.
Durante a fase de migração, em vez de copiar dados históricos para o Amazon Keyspaces, você pode definir TTL as configurações para permitir que os dados históricos expirem automaticamente no sistema antigo (Cassandra), aplicando somente as novas gravações no Amazon Keyspaces usando o método de gravação dupla. Com o tempo, com os dados antigos expirando continuamente no cluster do Cassandra e os novos dados gravados usando o método de gravação dupla, o Amazon Keyspaces automaticamente se atualiza para conter os mesmos dados do Cassandra.
Essa abordagem pode reduzir significativamente a quantidade de dados a serem migrados, resultando em um processo de migração mais eficiente e simplificado. Você pode considerar essa abordagem ao lidar com grandes conjuntos de dados com diferentes requisitos de retenção de dados. Para obter mais informações sobreTTL, consulteExpire dados com Time to Live (TTL) para Amazon Keyspaces (para Apache Cassandra).
Considere o exemplo a seguir de uma migração do Cassandra para o Amazon Keyspaces usando expiração de dados. TTL Neste exemplo, definimos TTL para os dois bancos de dados como 60 dias e mostramos como o processo de migração progride em um período de 90 dias. Ambos os bancos de dados recebem os mesmos dados recém-gravados durante esse período usando o método de gravação dupla. Vamos analisar três fases diferentes da migração, cada fase dura 30 dias.
O funcionamento do processo de migração em cada fase é mostrado nas imagens a seguir.
Após os primeiros 30 dias, o cluster Cassandra e o Amazon Keyspaces estão recebendo novas gravações. O cluster Cassandra também contém dados históricos que ainda não atingiram 60 dias de retenção, o que representa 50% dos dados no cluster.
Os dados com mais de 60 dias estão sendo excluídos automaticamente no cluster do Cassandra usando o. TTL Nesse ponto, o Amazon Keyspaces contém 50% dos dados armazenados no cluster Cassandra, que é composto pelas novas gravações menos os dados históricos.
Depois de 60 dias, tanto o cluster Cassandra quanto o Amazon Keyspaces contêm os mesmos dados gravados nos últimos 60 dias.
Em 90 dias, tanto o Cassandra quanto o Amazon Keyspaces contêm os mesmos dados e estão expirando na mesma taxa.
Este exemplo ilustra como evitar a etapa de upload de dados históricos usando TTL com uma data de expiração definida como 60 dias.
