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á.
# Como migrar para o Amazon Keyspaces (para Apache Cassandra)
A migração para o Amazon Keyspaces (para Apache Cassandra) apresenta uma série de benefícios interessantes para empresas e organizações. Veja a seguir algumas das principais vantagens que tornam o Amazon Keyspaces uma opção atraente para migração.
+ **Escalabilidade**: o Amazon Keyspaces foi concebido para lidar com grandes workloads e escalar perfeitamente para acomodar volumes e tráfego de dados crescentes. Com o Cassandra tradicional, o escalonamento não é realizado sob demanda e requer planejamento para futuros picos. Com o Amazon Keyspaces, é fácil aumentar ou reduzir suas tabelas verticalmente com base na demanda, garantindo que as aplicações possam lidar com picos repentinos de tráfego sem comprometer a performance.
+ **Performance**: o Amazon Keyspaces oferece acesso a dados de baixa latência, permitindo que as aplicações recuperem e processem dados com velocidade excepcional. Sua arquitetura distribuída garante que as operações de leitura e gravação sejam distribuídas em vários nós, oferecendo tempos de resposta consistentes de um dígito de milissegundo, mesmo com altas taxas de solicitação.
+ **Totalmente gerenciado**: o Amazon Keyspaces é um serviço totalmente gerenciado oferecido pela AWS. Isso significa que AWS lida com os aspectos operacionais do gerenciamento de banco de dados, incluindo provisionamento, configuração, aplicação de patches, backups e escalabilidade. Isso permite que você se concentre mais no desenvolvimento de aplicações e menos nas tarefas de administração do banco de dados.
+ **Arquitetura com tecnologia sem servidor**: o Amazon Keyspaces está equipado com tecnologia sem servidor. Você paga somente pela capacidade consumida, sem necessidade de provisionamento antecipado de capacidade. Você não tem servidores para gerenciar nem instâncias para escolher. Esse pay-per-request modelo oferece eficiência de custos e sobrecarga operacional mínima, pois você paga apenas pelos recursos que consome, sem a necessidade de provisionar e monitorar a capacidade.
+ **Flexibilidade do NoSQL com esquema**: o Amazon Keyspaces segue um modelo de dados NoSQL, oferecendo flexibilidade no design do esquema. Com o Amazon Keyspaces, é possível armazenar dados estruturados, semiestruturados e não estruturados, o que o torna adequado para lidar com tipos de dados diversos e dinâmicos. Além disso, o Amazon Keyspaces realiza a validação do esquema na gravação, permitindo uma evolução centralizada do modelo de dados. Essa flexibilidade permite ciclos de desenvolvimento mais rápidos e uma adaptação mais fácil às mudanças nos requisitos de negócios.
+ **Alta disponibilidade e durabilidade** — o Amazon Keyspaces replica dados em várias [zonas de disponibilidade](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) dentro de um Região da AWS, garantindo alta disponibilidade e durabilidade dos dados. Ele gerencia automaticamente a replicação, o failover e a recuperação, minimizando o risco de perda de dados ou interrupções no serviço. O Amazon Keyspaces oferece um SLA de disponibilidade de até 99,999%. Para obter ainda mais resiliência e leituras locais de baixa latência, o Amazon Keyspaces oferece [replicação em várias regiões](multiRegion-replication.md).
+ **Segurança e conformidade**: o Amazon Keyspaces integra-se ao AWS Identity and Access Management para oferecer um controle de acesso minucioso. Ele fornece criptografia em repouso e em trânsito, ajudando a melhorar a segurança dos dados. O Amazon Keyspaces foi avaliado por auditores terceirizados quanto à segurança e conformidade com programas específicos, incluindo HIPAA, PCI DSS e SOC, possibilitando que você atenda aos requisitos regulatórios. Para obter mais informações, consulte [Validação de conformidade do Amazon Keyspaces (para Apache Cassandra)](Keyspaces-compliance.md).
+ **Integração com o AWS ecossistema** — Como parte do AWS ecossistema, o Amazon Keyspaces se integra perfeitamente a outros Serviços da AWS, por exemplo, AWS CloudFormation Amazon e. CloudWatch AWS CloudTrail Essa integração permite criar arquiteturas sem servidor, aproveitar a infraestrutura como código e criar aplicações orientadas por dados em tempo real. Para obter mais informações, consulte [Monitoramento do Amazon Keyspaces (para Apache Cassandra)](monitoring-overview.md).
**Topics**
+ [Crie um plano de migração para migrar do Apache Cassandra para o Amazon Keyspaces](migrating-cassandra.md)
+ [Como selecionar a ferramenta certa para fazer upload ou migrar dados em massa para o Amazon Keyspaces](migrating-tools.md)
# Crie um plano de migração para migrar do Apache Cassandra para o Amazon Keyspaces
Para uma migração bem-sucedida do Apache Cassandra para o Amazon Keyspaces, recomendamos uma análise dos conceitos e das melhores práticas de migração aplicáveis, bem como uma comparação das opções disponíveis.
Este tópico descreve como o processo de migração funciona, apresentando vários conceitos-chave e as ferramentas e técnicas disponíveis para você. É possível avaliar as diferentes estratégias de migração para selecionar a mais adequada às suas necessidades.
**Topics**
+ [Compatibilidade funcional](#migrating-cassandra-compatibility)
+ [Custos estimados do Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Escolher uma estratégia de migração](#migrating-cassandra-strategy)
+ [Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas](migrating-online.md)
+ [Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md)
+ [Usando uma solução de migração híbrida: Apache Cassandra para Amazon Keyspaces](migrating-hybrid.md)
## Compatibilidade funcional
Considere cuidadosamente as diferenças funcionais entre o Apache Cassandra e o Amazon Keyspaces antes da migração. O Amazon Keyspaces oferece suporte a todas as operações de plano de dados do Cassandra comumente usadas, como criar espaços de chaves e tabelas, ler dados e gravar dados.
No entanto, existem algumas Cassandra que o APIs Amazon Keyspaces não suporta. Para obter mais informações sobre o suporte APIs, consulte[Cassandra APIs, operações, funções e tipos de dados compatíveis](cassandra-apis.md). Para obter uma visão geral de todas as diferenças funcionais entre o Amazon Keyspaces e o Apache Cassandra, consulte [Diferenças funcionais: Amazon Keyspaces versus Apache Cassandra](functional-differences.md).
Para comparar o Cassandra APIs e o esquema que você está usando com a funcionalidade compatível no Amazon Keyspaces, você pode executar um script de compatibilidade disponível no kit de ferramentas do Amazon Keyspaces em. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Como usar o script de compatibilidade**
1. Baixe o script de compatibilidade do Python [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)e mova-o para um local que tenha acesso ao seu cluster Apache Cassandra existente.
1. O script de compatibilidade usa parâmetros semelhantes a `CQLSH`. Para `--host` e `--port` insira o endereço IP e a porta que você usa para se conectar e executar consultas em um dos nós do Cassandra em seu cluster.
Se seu cluster Cassandra usa autenticação, você também precisa fornecer `-username` e `-password`. Para usar o script de compatibilidade, você pode executar o seguinte comando.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Custos estimados do Amazon Keyspaces
Esta seção fornece uma visão geral das informações que você precisa coletar das tabelas do Apache Cassandra para calcular o custo estimado do Amazon Keyspaces. Cada uma de suas tabelas exige tipos de dados diferentes, precisa oferecer suporte a diferentes consultas CQL e manter um tráfego distinto read/write .
Pensar em seus requisitos com base em tabelas se alinha aos modos de isolamento de recursos em nível de tabela e [capacidade de throughput de leitura/gravação](ReadWriteCapacityMode.md) do Amazon Keyspaces. Com o Amazon Keyspaces, você pode definir a capacidade de leitura/gravação e as [políticas de ajuste de escala automático](autoscaling.md) para tabelas de forma independente.
Compreender os requisitos das tabelas ajuda você a priorizar tabelas para migração com base na funcionalidade, no custo e no esforço de migração.
Colete as seguintes métricas da tabela do Cassandra antes de uma migração. Essas informações ajudam a estimar o custo da sua workload no Amazon Keyspaces.
+ **Nome da tabela**: o nome do espaço de chaves totalmente qualificado e o nome da tabela.
+ **Descrição**: uma descrição da tabela, por exemplo, como ela é usada ou que tipo de dados são armazenados nela.
+ **Média de leituras por segundo**: o número médio de leituras em nível de coordenadas na tabela em um grande intervalo de tempo.
+ **Média de gravações por segundo**: o número médio de gravações em nível de coordenadas na tabela em um grande intervalo de tempo.
+ **Tamanho médio da linha em bytes**: o tamanho médio da linha em bytes.
+ **Tamanho de armazenamento em GBs** — O tamanho bruto de armazenamento de uma tabela.
+ **Detalhamento da consistência de leitura**: a porcentagem de leituras que usam consistência eventual (`LOCAL_ONE` ou `ONE`) versus consistência forte (`LOCAL_QUORUM`).
Esta tabela mostra um exemplo das informações sobre suas tabelas que você precisa reunir ao planejar uma migração.
****
| Nome da tabela | Description | Média de leitura por segundo | Média de gravação por segundo | Tamanho médio da linha em bytes | Tamanho de armazenamento em GBs | Detalhamento de consistência de leitura |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | Usado para armazenar o histórico do carrinho de compras | 10.000 | 5.000 | 2.200 | 2.000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | Usado para armazenar as informações mais recentes do perfil | 20.000 | 1.000 | 850 | 1.000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### Como coletar métricas de tabela
Esta seção fornece instruções passo a passo sobre como coletar as métricas de tabela necessárias do seu cluster Cassandra existente. Essas métricas incluem tamanho da linha, tamanho da tabela e read/write solicitações por segundo (RPS). Eles permitem que você avalie os requisitos de capacidade de throughput de uma tabela do Amazon Keyspaces e estime os preços.
**Como coletar métricas de tabela na tabela de origem do Cassandra**
1. Determinar o tamanho da linha
O tamanho da linha é importante para determinar a capacidade de leitura e a utilização da capacidade de gravação no Amazon Keyspaces. O diagrama a seguir mostra a distribuição de dados típica em um intervalo de tokens do Cassandra.
![\[Um diagrama mostrando a distribuição típica de dados em um intervalo de tokens do Cassandra usando o particionador do murmur3.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Você pode usar um script de amostragem de tamanho de linha disponível [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)para coletar métricas de tamanho de linha para cada tabela em seu cluster do Cassandra.
O script exporta dados da tabela do Apache Cassandra usando `cqlsh` e `awk` para calcular o mínimo, o máximo, a média e o desvio padrão do tamanho da linha em um conjunto de amostra configurável de dados da tabela. O amostrador de tamanho de linha passa os argumentos para `cqlsh`, portanto, os mesmos parâmetros podem ser usados para se conectar e ler do seu cluster do Cassandra.
A instrução a seguir é um exemplo disso.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Para saber mais sobre como o tamanho da linha é calculado no Amazon Keyspaces, consulte [Estimar o tamanho da linha no Amazon Keyspaces](calculating-row-size.md).
1. Determinar o tamanho da tabela
Com o Amazon Keyspaces, você não precisa provisionar o armazenamento com antecedência. O Amazon Keyspaces monitora continuamente o tamanho faturável de suas tabelas para determinar suas cobranças de armazenamento. O armazenamento é cobrado por GB/mês. O tamanho da tabela do Amazon Keyspaces é baseado no tamanho bruto (não compactado) de uma única réplica.
Para monitorar o tamanho da tabela no Amazon Keyspaces, você pode usar a métrica `BillableTableSizeInBytes`, que é exibida para cada tabela em Console de gerenciamento da AWS.
Para estimar o tamanho faturável da sua tabela do Amazon Keyspaces, você pode usar um desses dois métodos:
+ Use o tamanho médio da linha e multiplique pelo número ou linhas.
Você pode estimar o tamanho da tabela Amazon Keyspaces multiplicando o tamanho médio da linha pelo número de linhas da tabela de origem do Cassandra. Use o script de amostra de tamanho de linha da seção anterior para capturar o tamanho médio da linha. Para capturar a contagem de linhas, você pode usar ferramentas como `dsbulk count` determinar o número total de linhas na tabela de origem.
+ Use o `nodetool` para coletar os metadados da tabela.
`Nodetool` é uma ferramenta administrativa fornecida na distribuição do Apache Cassandra que fornece uma visão sobre o estado do processo do Cassandra e retorna os metadados da tabela. Você pode usar `nodetool` para amostrar metadados sobre o tamanho da tabela e, com isso, extrapolar o tamanho da tabela no Amazon Keyspaces.
O comando a ser usado é `nodetool tablestats`. Tablestats retorna o tamanho e a taxa de compactação da tabela. O tamanho da tabela é armazenado como `tablelivespace` da tabela e você pode dividi-lo por `compression ratio`. Em seguida, multiplique esse valor de tamanho pelo número de nós. Por fim, divida pelo fator de replicação (normalmente três).
Essa é a fórmula completa do cálculo que você pode usar para avaliar o tamanho da tabela.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Vamos supor que seu cluster do Cassandra tenha 12 nós. A execução do `nodetool tablestats` comando retorna um `tablelivespace` de 200 GB e um `compression ratio` de 0,5. O espaço de chave tem um fator de replicação de três.
É assim que o cálculo desse exemplo se parece.
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. Capture o número de leituras e gravações
Para determinar os requisitos de capacidade e ajuste de escala para suas tabelas do Amazon Keyspaces, capture a taxa de solicitação de leitura e gravação de suas tabelas do Cassandra antes da migração.
O Amazon Keyspaces não tem servidor e você paga apenas pelo que usa. Em geral, o preço da read/write taxa de transferência no Amazon Keyspaces é baseado no número e no tamanho das solicitações.
Há dois modos de capacidade no Amazon Keyspaces:
+ [Sob demanda](ReadWriteCapacityMode.OnDemand.md): esta é uma opção de faturamento flexível capaz de servir centenas de solicitações por segundo sem a necessidade de planejamento de capacidade. Ele oferece pay-per-request preços para solicitações de leitura e gravação, para que você pague somente pelo que usa.
+ [Provisionada](ReadWriteCapacityMode.Provisioned.md): se você selecionar o modo de capacidade de throughput provisionada, especifique o número de leituras e gravações por segundo necessárias para seu aplicativo. Isso ajuda você a gerenciar o uso do Amazon Keyspaces para permanecer em ou abaixo de uma taxa de solicitação definida para manter a previsibilidade.
O modo provisionado oferece [ajuste de escala automático](autoscaling.md) para ajustar automaticamente sua taxa provisionada para aumentar ou reduzir a escala verticalmente para melhorar a eficiência operacional. Para obter mais informações sobre o gerenciamento de recursos com tecnologia sem servidor, consulte [Como gerenciar os recursos de tecnologia sem servidor no Amazon Keyspaces (para Apache Cassandra)](serverless_resource_management.md).
Como você provisiona a capacidade de throughput de leitura e gravação no Amazon Keyspaces separadamente, você precisa medir a taxa de solicitações para leituras e gravações em suas tabelas existentes de forma independente.
Para reunir as métricas de utilização mais precisas do seu cluster Cassandra existente, capture a média de solicitações por segundo (RPS) para operações de leitura e gravação em nível de coordenador durante um longo período de tempo para uma tabela agregada em todos os nós em um único data center.
Capturar o RPS médio em um período de pelo menos várias semanas captura picos e baixos em seus padrões de tráfego, conforme mostrado no diagrama a seguir.
![\[Um diagrama mostrando a taxa média de solicitações por segundo por dia durante um período de duas semanas.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-rps.png)
Você tem duas opções para determinar a taxa de solicitações de leitura e gravação da sua tabela do Cassandra.
+ Use o monitoramento existente do Cassandra
É possível usar as métricas mostradas na tabela a seguir para observar solicitações de leituras e gravações. Observe que os nomes das métricas podem mudar com base na ferramenta de monitoramento que você está usando.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/migrating-cassandra.html)
+ Usar a `nodetool`
Use `nodetool tablestats` e `nodetool info` para capturar a média de operações de leitura e gravação da tabela. `tablestats`retorna a contagem total de leituras e gravações a partir do momento em que o nó foi iniciado. `nodetool info` fornece o tempo de atividade de um nó em segundos.
Para receber a média de leituras e gravações por segundo, divida a contagem de leitura e gravação pelo tempo de atividade do nó em segundos. Em seguida, para leituras, você divide pelo nível de consistência e, para gravações, divide pelo fator de replicação. Esses cálculos são expressos nas fórmulas a seguir.
Fórmula para leituras médias por segundo:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
Fórmula para a média de gravações por segundo:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
Vamos supor que temos um cluster de 12 nós que está ativo há 4 semanas. `nodetool info`retorna 2.419.200 segundos de tempo de atividade e `nodetool tablestats` retorna 1 bilhão de gravações e 2 bilhões de leituras. Esse exemplo resultaria no cálculo a seguir.
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. Determine a utilização da capacidade da tabela
Para estimar a utilização média da capacidade, comece com as taxas médias de solicitação e o tamanho médio da linha da tabela de origem do Cassandra.
O Amazon Keyspaces usa unidades de *capacidade de leitura (RCUs) e unidades* de *capacidade de gravação* (WCUs) para medir a capacidade de transferência provisionada para leituras e gravações em tabelas. Para essa estimativa, usamos essas unidades para calcular as necessidades de capacidade de leitura e gravação da nova tabela do Amazon Keyspaces após a migração.
Posteriormente neste tópico, discutiremos como a escolha entre o modo de capacidade provisionada e sob demanda afeta o faturamento. Mas para a estimativa da utilização da capacidade neste exemplo, presumimos que a tabela esteja no modo provisionado.
+ **Leituras**: um RCU representa uma solicitação de leitura `LOCAL_QUORUM` ou duas solicitações de leitura `LOCAL_ONE` para uma linha com até 4 KB de tamanho. Se você precisar ler uma linha maior que 4 KB, a operação de leitura usará mais RCUs. O número total RCUs necessário depende do tamanho da linha e se você deseja usar `LOCAL_QUORUM` ou `LOCAL_ONE` ler a consistência.
Por exemplo, a leitura de uma linha de 8 KB requer 2 RCUs usando a consistência de `LOCAL_QUORUM` leitura e 1 RCU se você escolher a consistência de `LOCAL_ONE` leitura.
+ **Gravação**: um WCU representa uma gravação para uma linha com até 1 KB de tamanho. Todas as gravações estão usando `LOCAL_QUORUM` consistência e não há cobrança adicional pelo uso de transações leves (LWTs).
O número total WCUs necessário depende do tamanho da linha. Se você precisar gravar uma linha maior que 1 KB, a operação de gravação usa mais WCUs. Por exemplo, se o tamanho da linha for de 2 KB, você precisará de 2 WCUs para realizar uma solicitação de gravação.
A fórmula a seguir pode ser usada para estimar o necessário RCUs WCUs e.
+ A **capacidade de leitura em RCUs** pode ser determinada multiplicando as leituras por segundo pelo número de linhas lidas por leitura multiplicado pelo tamanho médio da linha dividido por 4 KB e arredondado para o número inteiro mais próximo.
+ A **capacidade de gravação em WCUs** pode ser determinada multiplicando o número de solicitações pelo tamanho médio da linha dividido por 1 KB e arredondado para o número inteiro mais próximo.
Isso é expresso nas fórmulas a seguir.
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
Por exemplo, se você estiver realizando 4.960 solicitações de leitura com um tamanho de linha de 2,5 KB em sua tabela do Cassandra, precisará de 4.960 no Amazon Keyspaces. RCUs Se você está realizando atualmente 1.653 solicitações de gravação por segundo com um tamanho de linha de 2,5 KB em sua tabela do Cassandra, você precisa de 4.959 por WCUs segundo no Amazon Keyspaces.
Esse exemplo é expresso nas fórmulas a seguir.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
O uso de `eventual consistency` permite que você economize até metade da capacidade de throughput em cada solicitação de leitura. Cada leitura final consistente pode consumir até 8 KB. Você pode calcular eventuais leituras consistentes multiplicando o cálculo anterior por 0,5, conforme mostrado na fórmula a seguir.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. Calcule a estimativa de preço mensal para o Amazon Keyspaces
Para estimar o faturamento mensal da tabela com base na taxa de transferência da read/write capacidade, você pode calcular os preços para o modo sob demanda e para o modo provisionado usando fórmulas diferentes e comparar as opções da sua tabela.
**Modo provisionado**: o consumo de capacidade de leitura e gravação é cobrado em uma taxa horária com base nas unidades de capacidade por segundo. Primeiro, divida essa taxa por 0,7 para representar a meta de utilização padrão de ajuste de escala automático de 70%. Em seguida, multiplique por 30 dias corridos, 24 horas por dia e preços tarifários regionais.
Esse cálculo está resumido nas fórmulas a seguir.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**Modo sob demanda**: a capacidade de leitura e gravação é cobrada de acordo com uma taxa por solicitação. Primeiro, multiplique a taxa de solicitações por 30 dias corridos e 24 horas por dia. Em seguida, divida por um milhão de unidades de solicitação. Por fim, multiplique pela taxa regional.
Esse cálculo está resumido nas fórmulas a seguir.
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## Escolher uma estratégia de migração
Você pode escolher entre as seguintes estratégias de migração ao migrar do Apache Cassandra para o Amazon Keyspaces:
+ **On-line**: essa é uma migração ao vivo usando gravações duplas para começar a gravar novos dados no Amazon Keyspaces e no cluster Cassandra simultaneamente. Esse tipo de migração é recomendado para aplicativos que exigem zero tempo de inatividade durante a migração e consistência de leitura após gravação.
Para saber mais sobre como planejar e implementar uma estratégia de migração on-line, consulte [Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas](migrating-online.md).
+ **Off-line**: essa técnica de migração envolve a cópia de um conjunto de dados do Cassandra para o Amazon Keyspaces durante uma janela de tempo de inatividade. A migração off-line pode simplificar o processo de migração, pois não exige alterações em seu aplicativo ou resolução de conflitos entre dados históricos e novas gravações.
Para saber mais sobre como planejar uma migração off-line, consulte [Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md).
+ **Híbrida**: essa técnica de migração permite que as alterações sejam replicadas para o Amazon Keyspaces quase em tempo real, mas sem consistência de leitura após gravação.
Para saber mais sobre como planejar uma migração híbrida, consulte [Usando uma solução de migração híbrida: Apache Cassandra para Amazon Keyspaces](migrating-hybrid.md).
Depois de analisar as técnicas de migração e as melhores práticas discutidas neste tópico, você pode colocar as opções disponíveis em uma árvore decisória para criar uma estratégia de migração com base em seus requisitos e recursos disponíveis.
# Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas
Se precisar manter a disponibilidade do aplicativo durante uma migração do Apache Cassandra para o Amazon Keyspaces, você pode preparar uma estratégia de migração on-line personalizada implementando os principais componentes discutidos neste tópico. Ao seguir essas melhores práticas para migrações on-line, você pode garantir que a disponibilidade e a read-after-write consistência dos aplicativos sejam mantidas durante todo o processo de migração, minimizando o impacto sobre seus usuários.
Ao criar uma estratégia de migração on-line do Apache Cassandra para o Amazon Keyspaces, você precisa considerar as seguintes etapas principais.
1. **Escrever novos dados**
+ Proxy **ZDM Dual Write para migração do Amazon Keyspaces — Use o proxy** ZDM Dual Write disponível no [Github para realizar a migração sem tempo de inatividade do Apache Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) para o Amazon Keyspaces. O ZDM Proxy executa gravações duplas sem a necessidade de refatorar aplicativos existentes e executa leituras duplas para validação da consulta.
+ Gravações duplas em aplicativos: você pode implementar gravações duplas em seu aplicativo usando bibliotecas e drivers de cliente do Cassandra existentes. Designe um banco de dados como líder e o outro como seguidor. As falhas de gravação no banco de dados de seguidores são registradas em uma [fila de mensagens não entregues (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para análise.
+ Gravações duplas no nível de mensagens: como alternativa, você pode configurar sua plataforma de mensagens existente para enviar gravações para o Cassandra e para o Amazon Keyspaces usando um consumidor adicional. Eventualmente, isso cria visualizações consistentes em ambos os bancos de dados.
1. **Migração de dados históricos**
+ Copiar dados históricos: você pode migrar dados históricos do Cassandra para o Amazon Keyspaces usando AWS Glue ou scripts personalizados de extração, transformação e carregamento (ETL). Gerencie a resolução de conflitos entre gravações duplas e cargas em massa usando técnicas como transações leves ou registros de data e hora.
+ Uso Time-To-Live (TTL): Para períodos mais curtos de retenção de dados, você pode usar o TTL no Cassandra e no Amazon Keyspaces para evitar o upload de dados históricos desnecessários. À medida que os dados antigos expiram no Cassandra e os novos dados são gravados por meio de gravações duplas, o Amazon Keyspaces acaba se atualizando.
1. **Validando dados**
+ Leituras duplas: implemente leituras duplas dos bancos de dados Cassandra (primário) e Amazon Keyspaces (secundário), comparando os resultados de forma assíncrona. As diferenças são registradas ou enviadas para uma DLQ.
+ Leituras de amostra: use as funções λ para amostrar e comparar dados periodicamente em ambos os sistemas, registrando quaisquer discrepâncias em um DLQ.
1. **Migrando o aplicativo**
+ Estratégia azul e verde: mude seu aplicativo para tratar o Amazon Keyspaces como o principal e o Cassandra como o armazenamento de dados secundário em uma única etapa. Monitore o desempenho e reverta se surgirem problemas.
+ Implantação canário: implemente gradualmente a migração primeiro para um subconjunto de usuários, aumentando incrementalmente o tráfego para o Amazon Keyspaces como principal até a migração completa.
1. **Desativação do Cassandra**
Depois que seu aplicativo for totalmente migrado para o Amazon Keyspaces e a consistência dos dados for validada, você poderá planejar a desativação do seu cluster Cassandra com base nas políticas de retenção de dados.
Ao planejar uma estratégia de migração on-line com esses componentes, você pode fazer a transição sem problemas para o serviço Amazon Keyspaces totalmente gerenciado com o mínimo de tempo de inatividade ou interrupção. As seções a seguir discutem esse componente em mais detalhes.
**Topics**
+ [Escrever novos dados durante uma migração on-line](migration-online-dw.md)
+ [Carregando dados históricos durante uma migração on-line](migration-online-historical.md)
+ [Validando a consistência dos dados durante uma migração on-line](migration-online-validation.md)
+ [Migrando o aplicativo durante uma migração on-line](migration-online-app-migration.md)
+ [Desativação do Cassandra após uma migração on-line](migration-online-decommission.md)
# Escrever novos dados durante uma migração on-line
A primeira etapa em um plano de migração on-line é garantir que todos os novos dados gravados pelo aplicativo sejam armazenados nos dois bancos de dados, em seu cluster Cassandra existente e no Amazon Keyspaces. O objetivo é fornecer uma visão consistente dos dois armazenamentos de dados. Você pode fazer isso aplicando todas as novas gravações nos dois bancos de dados. Para implementar gravações duplas, considere uma das três opções a seguir.
+ Proxy **ZDM Dual Write para migração do Amazon Keyspaces — Usando o proxy** ZDM para Amazon Keyspaces disponível no Github, você pode migrar suas cargas de trabalho do Apache [Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) para o Amazon Keyspaces sem tempo de inatividade do aplicativo. Essa solução aprimorada implementa as AWS melhores práticas e amplia os recursos oficiais do ZDM Proxy.
+ Execute migrações on-line entre o Apache Cassandra e o Amazon Keyspaces.
+ Grave dados nas tabelas de origem e de destino simultaneamente sem refatorar os aplicativos.
+ Valide consultas por meio de operações de leitura dupla.
A solução oferece os seguintes aprimoramentos para trabalhar com o Amazon Keyspaces e com o AWS Amazon Keyspaces.
+ **Implantação de contêiner** — Use uma imagem Docker pré-configurada do Amazon Elastic Container Registry (Amazon ECR) para implantações acessíveis por VPC.
+ **Infraestrutura como código** — implante usando AWS CloudFormation modelos para configuração automáticaAWS Fargate.
+ **Compatibilidade com Amazon Keyspaces** — Acesse tabelas do sistema com adaptações personalizadas para o Amazon Keyspaces.
A solução é executada no Amazon ECS com o Fargate, fornecendo escalabilidade sem servidor com base em suas demandas de carga de trabalho. Um balanceador de carga de rede distribui o tráfego de entrada do aplicativo em várias tarefas do Amazon ECS para obter alta disponibilidade.
![\[Implementação do proxy de gravação dupla ZDM para migrar dados do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Gravações duplas do aplicativo**: você pode implementar gravações duplas com o mínimo de alterações no código do aplicativo, aproveitando as bibliotecas e os drivers existentes do cliente Cassandra. Você pode implementar gravações duplas em seu aplicativo existente ou criar uma nova camada na arquitetura para lidar com gravações duplas. Para obter mais informações e um estudo de caso de um cliente que mostra como as gravações duplas foram implementadas em um aplicativo existente, consulte o estudo de [caso de migração do Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Ao implementar gravações duplas, você pode designar um banco de dados como líder e o outro banco de dados como seguidor. Isso permite que você continue gravando no banco de dados original ou principal sem permitir que falhas de gravação no banco de dados seguidor ou no banco de dados de destino interrompam o caminho crítico do seu aplicativo.
Em vez de tentar novamente gravações com falha no seguidor, você pode usar o Amazon Simple Queue Service para registrar gravações com falha em uma [fila de mensagens não entregues (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)). O DLQ permite que você analise as gravações com falha no seguidor e determine por que o processamento não foi bem-sucedido no banco de dados de destino.
Para uma implementação de gravação dupla mais sofisticada, você pode seguir as AWS melhores práticas para criar uma sequência de transações locais usando o [padrão de saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Um padrão saga certifica que, se uma transação falhar, a saga executa transações compensatórias para reverter as alterações do banco de dados feitas pelas transações anteriores.
Ao usar gravações duplas para uma migração on-line, você pode configurar as gravações duplas seguindo o padrão da saga para que cada gravação seja uma transação local para garantir operações atômicas em bancos de dados heterogêneos. Para obter mais informações sobre como projetar aplicativos distribuídos usando os padrões de design recomendados para oNuvem AWS, consulte [Padrões de design, arquiteturas e implementações de nuvem](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implementando gravações duplas na camada do aplicativo ao migrar do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Gravações duplas no nível de mensagens**: em vez de implementar gravações duplas na camada do aplicativo, você pode usar seu nível de mensagens existente para realizar gravações duplas no Cassandra e no Amazon Keyspaces.
Para fazer isso, você pode configurar um consumidor adicional em sua plataforma de mensagens para enviar gravações para os dois armazenamentos de dados. Essa abordagem fornece uma estratégia simples de baixo código usando a camada de mensagens para criar duas visualizações em ambos os bancos de dados que acabam sendo consistentes.
# Carregando dados históricos durante uma migração on-line
Depois de implementar gravações duplas para garantir que novos dados sejam gravados em ambos os 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 os novos dados quanto os 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 scripts personalizados para extrair, transformar e carregar (ETL) os dados. Para obter mais informações sobre como usar AWS Glue para carregar dados históricos, consulte[Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md).
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](functional-differences.md#functional-differences.light-transactions) (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](client-side-timestamps.md).
+ **Usando Time-to-Live (TTL)** — Para períodos de retenção de dados menores que 30, 60 ou 90 dias, você pode usar o 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. O TTL permite definir um período de tempo 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 as configurações de TTL 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 sobre a TTL, consulte [Dados expirados com vida útil (TTL) para Amazon Keyspaces (para Apache Cassandra)](TTL.md).
Considere o exemplo a seguir de uma migração do Cassandra para o Amazon Keyspaces usando a expiração de dados TTL. Neste exemplo, definimos o TTL para ambos os bancos de dados para 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.
![\[Usando TTL para expirar dados históricos ao migrar do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 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 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.
1. Depois de 60 dias, tanto o cluster Cassandra quanto o Amazon Keyspaces contêm os mesmos dados gravados nos últimos 60 dias.
1. Em 90 dias, tanto o Cassandra quanto o Amazon Keyspaces contêm os mesmos dados e estão expirando os dados na mesma taxa.
Este exemplo ilustra como evitar a etapa de carregamento de dados históricos usando TTL com uma data de expiração definida como 60 dias.
# Validando a consistência dos dados durante uma migração on-line
A próxima etapa do processo de migração on-line é a validação de dados. As gravações duplas estão adicionando novos dados ao seu banco de dados do Amazon Keyspaces e você concluiu a migração dos dados históricos usando upload em massa ou expiração de dados com TTL.
Agora você pode usar a fase de validação para confirmar se os dois armazenamentos de dados contêm, de fato, os mesmos dados e retornam os mesmos resultados de leitura. Você pode escolher uma das duas opções a seguir para validar se os dois bancos de dados contêm dados idênticos.
+ **Leituras duplas**: para validar se o banco de dados de origem e o banco de dados de destino contêm o mesmo conjunto de dados históricos e recém-gravados, você pode implementar leituras duplas. Para fazer isso, você lê o Cassandra principal e o banco de dados secundário do Amazon Keyspaces de forma semelhante ao método de gravação dupla e compara os resultados de forma assíncrona.
Os resultados do banco de dados primário são retornados ao cliente e os resultados do banco de dados secundário são usados para validar em relação ao conjunto de resultados primário. As diferenças encontradas podem ser registradas ou enviadas para uma [fila de mensagens não entregues (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para posterior reconciliação.
No diagrama a seguir, o aplicativo está realizando uma leitura síncrona do Cassandra (que é o armazenamento de dados primário) e uma leitura assíncrona do Amazon Keyspaces, que é o armazenamento de dados secundário.
![\[Usando leituras duplas para validar a consistência dos dados durante uma migração on-line do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Exemplos de leituras** — Uma solução alternativa que não exige alterações no código do aplicativo é usar AWS Lambda funções para obter amostras periódicas e aleatórias de dados do cluster Cassandra de origem e do banco de dados Amazon Keyspaces de destino.
Essas funções do Lambda podem ser configuradas para serem executadas em intervalos regulares. A função do Lambda recupera um subconjunto aleatório de dados dos sistemas de origem e destino e, em seguida, realiza uma comparação dos dados amostrados. Quaisquer discrepâncias ou incompatibilidades entre os dois conjuntos de dados podem ser registradas e enviadas para uma [fila de mensagens não entregues (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) dedicada para posterior reconciliação.
Esse processo é ilustrado no diagrama a seguir.
![\[Usando leituras de amostra para validar a consistência dos dados durante a migração on-line do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migrando o aplicativo durante uma migração on-line
Na quarta fase de uma migração on-line, você está migrando seu aplicativo e fazendo a transição para o Amazon Keyspaces como armazenamento de dados primário. Isso significa que você alterna seu aplicativo para ler e gravar diretamente de e para o Amazon Keyspaces. Para garantir o mínimo de interrupção para seus usuários, esse deve ser um processo bem planejado e coordenado.
Duas soluções diferentes recomendadas para migração de aplicativos estão disponíveis: a estratégia de recorte azul esverdeado e a estratégia de corte canário. As seções a seguir descrevem essas estratégias em mais detalhes.
+ **Estratégia azul e verde**: usando essa abordagem, você muda seu aplicativo para tratar o Amazon Keyspaces como o armazenamento de dados primário e o Cassandra como o armazenamento de dados secundário em uma única etapa. Você pode fazer isso usando um sinalizador de AWS AppConfig recurso para controlar a eleição dos armazenamentos de dados primários e secundários na instância do aplicativo. Para obter mais informações sobre sinalizadores de atributos, consulte [Creating a feature flag configuration profile in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Depois de tornar o Amazon Keyspaces o armazenamento de dados principal, você monitora o comportamento e o desempenho do aplicativo, garantindo que o Amazon Keyspaces atenda aos seus requisitos e que a migração seja bem-sucedida.
Por exemplo, se você implementou leituras duplas para seu aplicativo, durante a fase de migração do aplicativo, você faz a transição das leituras primárias do Cassandra para o Amazon Keyspaces e as leituras secundárias do Amazon Keyspaces para o Cassandra. Após a transição, você continua monitorando e comparando os resultados conforme descrito na seção de [validação de dados](migration-online-validation.md) para garantir a consistência em ambos os bancos de dados antes de desativar o Cassandra.
Se você detectar algum problema, poderá reverter rapidamente para o estado anterior revertendo para o Cassandra como o armazenamento de dados primário. Você só prossegue para a fase de descomissionamento da migração se o Amazon Keyspaces estiver atendendo a todas as suas necessidades como armazenamento de dados primário.
![\[Usando a estratégia azul e verde para migrar um aplicativo do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Estratégia canário**: nessa abordagem, você gradualmente implementa a migração para um subconjunto de seus usuários ou tráfego. Inicialmente, uma pequena porcentagem do tráfego do seu aplicativo, por exemplo, 5% de todo o tráfego é roteado para a versão usando o Amazon Keyspaces como armazenamento de dados primário, enquanto o restante do tráfego continua usando o Cassandra como armazenamento de dados primário.
Isso permite que você teste minuciosamente a versão migrada com tráfego real e monitore seu desempenho, estabilidade e investigue possíveis problemas. Se você não detectar nenhum problema, poderá aumentar incrementalmente a porcentagem de tráfego roteado para o Amazon Keyspaces até que ele se torne o armazenamento de dados principal para todos os usuários e tráfego.
Essa implantação gradual minimiza o risco de interrupções generalizadas no serviço e permite um processo de migração mais controlado. Se surgirem problemas críticos durante a implantação canário, você poderá reverter rapidamente para a versão anterior usando o Cassandra como armazenamento de dados primário para o segmento de tráfego afetado. Você só prossegue para a fase de descomissionamento da migração depois de validar que o Amazon Keyspaces processa 100% dos seus usuários e tráfego conforme o esperado.
O diagrama a seguir ilustra as etapas individuais da estratégia canário.
![\[Usando a estratégia canário para migrar um aplicativo do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Desativação do Cassandra após uma migração on-line
Depois que a migração do aplicativo estiver concluída, seu aplicativo estiver totalmente em execução no Amazon Keyspaces e você tiver validado a consistência dos dados por um período de tempo, você poderá planejar a desativação do seu cluster Cassandra. Durante essa fase, você pode avaliar se os dados restantes em seu cluster do Cassandra precisam ser arquivados ou podem ser excluídos. Isso depende das políticas da sua organização para tratamento e retenção de dados.
Ao seguir essa estratégia e considerar as melhores práticas recomendadas descritas neste tópico ao planejar sua migração on-line do Cassandra para o Amazon Keyspaces, você pode garantir uma transição perfeita para o Amazon Keyspaces e, ao mesmo tempo, read-after-write manter a consistência e a disponibilidade do seu aplicativo.
A migração do Apache Cassandra para o Amazon Keyspaces pode oferecer vários benefícios, incluindo redução da sobrecarga operacional, ajuste de escala automático, segurança aprimorada e uma estrutura que ajuda você a atingir suas metas de conformidade. Ao planejar uma estratégia de migração on-line com gravações duplas, upload de dados históricos, validação de dados e implantação gradual, você pode garantir uma transição tranquila com o mínimo de interrupção para seu aplicativo e seus usuários.
A implementação da estratégia de migração on-line discutida neste tópico permite que você valide os resultados da migração, identifique e resolva quaisquer problemas e, por fim, desative sua implantação atual do Cassandra em favor do serviço Amazon Keyspaces totalmente gerenciado.
# Processo de migração off-line: Apache Cassandra para Amazon Keyspaces
As migrações off-line são adequadas para quando é possível permitir tempo de inatividade para realizar a migração. É comum entre as empresas ter janelas de manutenção para patches, grandes lançamentos ou tempo de inatividade para atualizações de hardware ou atualizações importantes. A migração off-line pode usar essa janela para copiar dados e transferir o tráfego do aplicativo do Apache Cassandra para o Amazon Keyspaces.
A migração off-line reduz as modificações no aplicativo porque não exige comunicação simultânea com o Cassandra e o Amazon Keyspaces. Além disso, com o fluxo de dados pausado, o estado exato pode ser copiado sem manter as mutações.
Neste exemplo, usamos o Amazon Simple Storage Service (Amazon S3) como uma área de preparação de dados durante a migração off-line para minimizar o tempo de inatividade. Você pode importar automaticamente os dados armazenados no formato Parquet no Amazon S3 em uma tabela do Amazon Keyspaces usando o conector Spark Cassandra e AWS Glue. Veja a seção a seguir uma visão geral de alto nível do processo. Você pode encontrar exemplos de código para esse processo no [Github.](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue)
O processo de migração offline do Apache Cassandra para o Amazon Keyspaces usando o Amazon S3 requer os seguintes trabalhos. AWS Glue AWS Glue
1. Um trabalho de ETL que extrai e transforma dados de CQL e os armazena em um bucket do Amazon S3.
1. Um segundo trabalho que importa os dados do bucket para o Amazon Keyspaces.
1. Um terceiro trabalho para importar dados incrementais.
**Como realizar uma migração off-line do Cassandra para o Amazon Keyspaces em execução na Amazon EC2 em uma Amazon Virtual Private Cloud**
1. Primeiro, você pode AWS Glue exportar dados da tabela do Cassandra no formato Parquet e salvá-los em um bucket do Amazon S3. Você precisa executar um AWS Glue trabalho usando um AWS Glue conector para uma VPC onde reside a EC2 instância da Amazon que executa o Cassandra. Em seguida, usando o endpoint privado do Amazon S3, você pode salvar dados no bucket do Amazon S3.
O diagrama a seguir ilustra essas etapas:
![\[Migração de dados do Apache Cassandra da Amazon EC2 em execução em uma VPC para um bucket do Amazon S3 usando. AWS Glue\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Embaralhe os dados no bucket do Amazon S3 para melhorar a randomização de dados. Dados importados uniformemente permitem um tráfego mais distribuído na tabela de destino.
Essa etapa é necessária ao exportar dados do Cassandra com partições grandes (partições com mais de 1000 linhas) para evitar padrões de teclas de atalho ao inserir os dados no Amazon Keyspaces. Problemas com teclas de atalho causam `WriteThrottleEvents` no Amazon Keyspaces e resultam em maior tempo de carregamento.
![\[Um AWS Glue trabalho embaralha os dados de um bucket do Amazon S3 e os retorna para outro bucket do Amazon S3.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Use outro AWS Glue trabalho para importar dados do bucket do Amazon S3 para o Amazon Keyspaces. Os dados embaralhados no bucket do Amazon S3 são armazenados no formato Parquet.
![\[O trabalho de AWS Glue importação pega dados embaralhados do bucket do Amazon S3 e os move para uma tabela do Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-import.png)
Para obter mais informações sobre o processo de migração off-line, consulte o workshop [Amazon Keyspaces with AWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# Usando uma solução de migração híbrida: Apache Cassandra para Amazon Keyspaces
A solução de migração a seguir pode ser considerada um híbrido entre migração on-line e off-line. Com essa abordagem híbrida, os dados são gravados no banco de dados de destino quase em tempo real, sem fornecer consistência de leitura após gravação. Isso significa que os dados recém-gravados não estarão imediatamente disponíveis e que atrasos são esperados. Se você precisar de consistência de leitura após gravação, consulte [Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas](migrating-online.md).
Para uma migração quase em tempo real do Apache Cassandra para o Amazon Keyspaces, você pode escolher entre dois métodos disponíveis.
+ **CQLReplicator**— (Recomendado) CQLReplicator é um utilitário de código aberto disponível no [Github](https://github.com/aws-samples/cql-replicator) que ajuda você a migrar dados do Apache Cassandra para o Amazon Keyspaces quase em tempo real.
Para determinar as gravações e atualizações a serem propagadas para o banco de dados de destino, CQLReplicator escaneia o intervalo de tokens do Apache Cassandra e usa um AWS Glue trabalho para remover eventos duplicados e aplicar gravações e atualizações diretamente no Amazon Keyspaces.
+ **Captura de dados de alterações (CDC)**: se você estiver familiarizado com o Cassandra CDC, o recurso CDC integrado do Apache Cassandra, que permite capturar alterações copiando o log de confirmação em um diretório CDC separado, é outra opção para implementar uma migração híbrida.
Você pode fazer isso replicando as alterações de dados no Amazon Keyspaces, tornando o CDC uma opção alternativa para cenários de migração de dados.
Se você não precisar de consistência de leitura após gravação, você pode usar o pipeline CQLReplicator ou o CDC para migrar dados do Apache Cassandra para o Amazon Keyspaces com base em suas preferências e familiaridade com as ferramentas usadas em cada solução. Serviços da AWS Usar esses métodos para migrar dados quase em tempo real pode ser considerado uma abordagem híbrida de migração que oferece uma alternativa à migração on-line.
Essa estratégia é considerada uma abordagem híbrida porque, além das opções descritas neste tópico, você precisa implementar algumas etapas do progresso da migração on-line, por exemplo, a cópia histórica dos dados e as estratégias de migração de aplicativos discutidas no tópico de [migração on-line](migrating-online.md).
As seções a seguir detalham mais as opções de migração híbrida.
**Topics**
+ [Migre dados usando CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migre dados usando a captura de dados de alteração (CDC)](migration-hybrid-cdc.md)
# Migre dados usando CQLReplicator
Com [CQLReplicator](https://github.com/aws-samples/cql-replicator), você pode ler dados do Apache Cassandra quase em tempo real por meio da digitalização inteligente do token ring do Cassandra usando consultas CQL. CQLReplicator não usa o Cassandra CDC e, em vez disso, implementa uma estratégia de armazenamento em cache para reduzir as penalidades de desempenho de escaneamentos completos.
Para reduzir o número de gravações no destino, remove CQLReplicator automaticamente os eventos de replicação duplicados. Com isso CQLReplicator, você pode ajustar a replicação de alterações do banco de dados de origem para o banco de dados de destino, permitindo uma migração quase em tempo real dos dados do Apache Cassandra para o Amazon Keyspaces.
O diagrama a seguir mostra a arquitetura típica de um CQLReplicator trabalho usandoAWS Glue.
1. **Para permitir o acesso ao Apache Cassandra em execução em uma VPC privada, configure uma AWS Glue conexão com o tipo de conexão Rede.**
1. Para remover duplicatas e ativar o armazenamento em cache de chaves com o CQLReplicator trabalho, configure o Amazon Simple Storage Service (Amazon S3).
1. O banco de dados de origem verificado do fluxo de CQLReplicator trabalho muda diretamente para o Amazon Keyspaces.
![\[Usando CQLReplicator para migrar dados do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Para obter mais informações sobre o uso do processo de migração CQLReplicator, consulte a postagem a seguir no blog de AWS banco de dados [Migrar cargas de trabalho do Cassandra para o Amazon Keyspaces CQLReplicator usando e a orientação prescritiva Migrar cargas](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) [de trabalho AWS do Apache](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) Cassandra para o Amazon Keyspaces usando. AWS Glue
# Migre dados usando a captura de dados de alteração (CDC)
Se você já está familiarizado com a configuração de um pipeline de captura de dados de alteração (CDC) com o [Debezium](https://debezium.io/), você pode usar essa opção para migrar dados para o Amazon Keyspaces como alternativa ao uso. CQLReplicator O Debezium é uma plataforma distribuída de código aberto para CDC, projetada para monitorar um banco de dados e capturar mudanças em nível de linha de forma confiável.
O [conector Debezium para Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) carrega as alterações no Amazon Managed Streaming for Apache Kafka (Amazon MSK) para que elas possam ser consumidas e processadas por consumidores downstream que, por sua vez, gravam os dados no Amazon Keyspaces. Para obter mais informações, consulte a [orientação para a migração contínua de dados do Apache Cassandra para o Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
Para resolver quaisquer possíveis problemas de consistência de dados, você pode implementar um processo com o Amazon MSK em que um consumidor compara as chaves ou partições no Cassandra com as do Amazon Keyspaces.
Para implementar essa solução com sucesso, recomendamos considerar o seguinte.
+ Como analisar o registro de confirmação do CDC, por exemplo, como remover eventos duplicados.
+ Como manter o diretório CDC, por exemplo, como excluir registros antigos.
+ Como lidar com falhas parciais no Apache Cassandra, por exemplo, se uma gravação só for bem-sucedida em uma das três réplicas.
+ Como lidar com a alocação de recursos, por exemplo, aumentando o tamanho da instância para atender aos requisitos adicionais de CPU, memória, DISCO e E/S para o processo CDC que ocorre em um nó.
Esse padrão trata as mudanças do Cassandra como uma “dica” de que uma chave pode ter mudado em relação ao seu estado anterior. Para determinar se há alterações a serem propagadas para o banco de dados de destino, você deve primeiro ler do cluster Cassandra de origem usando uma operação de `LOCAL_QUORUM` para receber os registros mais recentes e depois gravá-los no Amazon Keyspaces.
No caso de exclusões ou atualizações de intervalos, talvez seja necessário realizar uma comparação com a partição inteira para determinar quais eventos de gravação ou atualização precisam ser gravados no banco de dados de destino.
Nos casos em que as gravações não são idempotentes, você também precisa comparar suas gravações com o que já está no banco de dados de destino antes de gravar no Amazon Keyspaces.
O diagrama a seguir mostra a arquitetura típica de um pipeline CDC usando o Debezium e o Amazon MSK.
![\[Usando um pipeline de captura de dados de alteração para migrar dados do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)
# Como selecionar a ferramenta certa para fazer upload ou migrar dados em massa para o Amazon Keyspaces
Nesta seção, você pode analisar as diferentes ferramentas que você pode usar para carregar ou migrar dados em massa para o Amazon Keyspaces e aprender como selecionar a ferramenta correta com base em suas necessidades. Além disso, esta seção fornece uma visão geral e casos de uso dos step-by-step tutoriais disponíveis que demonstram como importar dados para o Amazon Keyspaces.
Para analisar as estratégias disponíveis para migrar workloads do Apache Cassandra para o Amazon Keyspaces, consulte [Crie um plano de migração para migrar do Apache Cassandra para o Amazon Keyspaces](migrating-cassandra.md).
+ **Ferramentas de migração**
+ Com a [calculadora de preços do Amazon Keyspaces (para Apache Cassandra)](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra) disponível no Github, você pode estimar seus custos mensais do Amazon Keyspaces com base na sua carga de trabalho atual do Apache Cassandra. Insira métricas da saída de status do nodetool do Cassandra e da configuração sem servidor pretendida para o Amazon Keyspaces para comparar os custos diretos entre as duas soluções. Observe que essa calculadora se concentra apenas nos custos operacionais do Amazon Keyspaces em comparação com sua implantação atual do Cassandra. Não inclui fatores de custo total de propriedade (TCO), como manutenção da infraestrutura, sobrecarga operacional ou custos de suporte para o Cassandra.
+ **Proxy ZDM Dual Write para migração do Amazon Keyspaces — O ZDM Dual Write Proxy disponível no [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) oferece suporte à migração** sem tempo de inatividade do Apache Cassandra para o Amazon Keyspaces.
+ **CQLReplicator**— CQLReplicator é um utilitário de código aberto disponível no [Github](https://github.com/aws-samples/cql-replicator) que ajuda você a migrar dados do Apache Cassandra para o Amazon Keyspaces quase em tempo real.
Para obter mais informações, consulte [Migre dados usando CQLReplicator](migration-hybrid-cql-rep.md).
+ Para saber mais sobre como usar o Amazon Managed Streaming for Apache Kafka para implementar um processo de [migração on-line](migrating-online.md) com gravação dupla, consulte [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
+ Para grandes migrações, considere usar uma ferramenta de extração, transformação e carregamento (ETL). Você pode usar AWS Glue para realizar migrações de transformação de dados de forma rápida e eficaz. Para obter mais informações, consulte [Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md).
+ Para saber como usar o conector Apache Cassandra do Spark para gravar dados no Amazon Keyspaces, consulte [Tutorial: Integre com o Apache Spark para importar ou exportar dados](spark-integrating.md).
+ Comece rapidamente a carregar dados no Amazon Keyspaces usando o comando cqlsh `COPY FROM`. O cqlsh está incluído no Apache Cassandra e é mais adequado para carregar pequenos conjuntos de dados ou dados de teste. Para step-by-step obter instruções, consulte[Tutorial: Como carregar dados no Amazon Keyspaces usando cqlsh](bulk-upload.md).
+ Você também pode usar o DataStax Bulk Loader for Apache Cassandra para carregar dados no Amazon Keyspaces usando o comando. `dsbulk` DSBulk[fornece recursos de importação mais robustos do que o cqlsh e está disponível no GitHub repositório.](https://github.com/datastax/dsbulk) Para step-by-step obter instruções, consulte[Tutorial: Carregando dados no Amazon Keyspaces usando DSBulk](dsbulk-upload.md).
Considerações gerais sobre uploads de dados para o Amazon Keyspaces
+ **Divida o upload de dados em componentes menores.**
Considere as seguintes unidades de migração e sua presença potencial em termos de tamanho de dados brutos. O upload de quantidades menores de dados em uma ou mais fases pode ajudar a simplificar sua migração.
+ **Por cluster**: migre todos os seus dados do Cassandra de uma só vez. Essa abordagem pode ser adequada para clusters menores.
+ **Por espaço de chaves ou tabela**: divida sua migração em grupos de espaços de chaves ou tabelas. Essa abordagem pode ajudá-lo a migrar dados em fases com base nos requisitos de cada workload.
+ **Por dados**: considere migrar dados para um grupo específico de usuários ou produtos, para reduzir ainda mais o tamanho dos dados.
+ **Priorize quais dados carregar primeiro com base na simplicidade.**
Considere se você tem dados que poderiam ser migrados primeiro com mais facilidade – por exemplo, dados que não mudam em horários específicos, dados de trabalhos em lotes noturnos, dados não usados em horários off-line ou dados de aplicativos internos.
**Topics**
+ [Tutorial: Como carregar dados no Amazon Keyspaces usando cqlsh](bulk-upload.md)
+ [Tutorial: Carregando dados no Amazon Keyspaces usando DSBulk](dsbulk-upload.md)
# Tutorial: Como carregar dados no Amazon Keyspaces usando cqlsh
Este tutorial orienta você no processe de migração de dados do Apache Cassandra para o Amazon Keyspaces usando o comando `cqlsh COPY FROM`. O comando `cqlsh COPY FROM` é útil para carregar pequenos conjuntos de dados de forma rápida e fácil no Amazon Keyspaces para fins acadêmicos ou de teste. Para obter mais informações sobre como migrar workloads de produção, consulte [Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md). Você concluirá as seguintes etapas neste tutorial:
Pré-requisitos — Configure uma AWS conta com credenciais, crie um arquivo JKS trust store para o certificado e configure para se conectar `cqlsh` ao Amazon Keyspaces.
1. **Crie CSV de origem e tabela de destino**: prepare um arquivo CSV como dados de origem e crie o keyspace e a tabela de destino no Amazon Keyspaces.
1. **Prepare os dados**: randomize os dados no arquivo CSV e analise-os para determinar os tamanhos médio e máximo das linhas.
1. **Defina a capacidade de taxa de transferência** — calcule as unidades de capacidade de gravação necessárias (WCUs) com base no tamanho dos dados e no tempo de carregamento desejado, e configure a capacidade provisionada da tabela.
1. **Configurar parâmetros cqlsh**: determine os valores ideais para parâmetros de`cqlsh COPY FROM` como `INGESTRATE`, `NUMPROCESSES`, `MAXBATCHSIZE` e `CHUNKSIZE` distribua a workload uniformemente.
1. **Execute o comando `cqlsh COPY FROM`**: execute o comando `cqlsh COPY FROM` para carregar os dados do arquivo CSV para a tabela do Amazon Keyspaces e monitorar o progresso.
Solução de problemas: resolva problemas comuns, como solicitações inválidas, erros do analisador, erros de capacidade e erros de cqlsh durante o processo de upload de dados.
**Topics**
+ [Pré-requisitos: etapas a serem concluídas antes de fazer o upload de dados usando `cqlsh COPY FROM`](bulk-upload-prequs.md)
+ [Etapa 1: criar o arquivo CSV de origem e uma tabela de destino para o carregamento de dados](bulk-upload-source.md)
+ [Etapa 2: Preparar os dados de origem para um carregamento de dados bem-sucedido](bulk-upload-prepare-data.md)
+ [Etapa 3: definir a capacidade de throughput da tabela](bulk-upload-capacity.md)
+ [Etapa 4: Definir configurações de `cqlsh COPY FROM`](bulk-upload-config.md)
+ [Etapa 5: Executar o comando `cqlsh COPY FROM` para carregar dados do arquivo CSV para a tabela de destino](bulk-upload-run.md)
+ [Solução de problemas](bulk-upload-troubleshooting.md)
# Pré-requisitos: etapas a serem concluídas antes de fazer o upload de dados usando `cqlsh COPY FROM`
É necessário concluir as tarefas a seguir antes de iniciar este tutorial.
1. Se você ainda não fez isso, inscreva-se em um Conta da AWS seguindo as etapas em[Conf AWS Identity and Access Management iguração](accessing.md#SettingUp.IAM).
1. Crie credenciais específicas do serviço seguindo as etapas em [Crie credenciais específicas do serviço para acesso programático ao Amazon Keyspaces](programmatic.credentials.ssc.md).
1. Configure a conexão shell do Cassandra Query Language (cqlsh) e confirme se você pode se conectar ao Amazon Keyspaces seguindo as etapas em [Usar `cqlsh` para se conectar ao Amazon Keyspaces](programmatic.cqlsh.md).
# Etapa 1: criar o arquivo CSV de origem e uma tabela de destino para o carregamento de dados
Neste tutorial, usamos um arquivo de valores separados por vírgula (CSV) com o nome `keyspaces_sample_table.csv` como arquivo de origem para a migração de dados. O arquivo de amostra fornecido contém algumas linhas de dados de uma tabela com o nome `book_awards`.
1. Criar o arquivo de origem. Você pode escolher uma das seguintes opções:
+ Baixe o arquivo CSV de amostra (`keyspaces_sample_table.csv`) contido no seguinte arquivo [samplemigration.zip](samples/samplemigration.zip). Descompacte o arquivo e anote o caminho até `keyspaces_sample_table.csv`.
+ Para preencher um arquivo CSV com seus próprios dados armazenados em um banco de dados do Apache Cassandra, você pode preencher o arquivo CSV de origem usando a instrução `cqlsh` `COPY TO`, conforme mostrado no exemplo a seguir.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
Certifique-se de que o arquivo CSV criado atenda aos seguintes requisitos:
+ A primeira linha contém os nomes das colunas.
+ Os nomes das colunas no arquivo CSV de origem correspondem aos nomes das colunas na tabela de destino.
+ Os dados são delimitados por uma vírgula.
+ Todos os valores de dados são tipos de dados válidos do Amazon Keyspaces. Consulte [Tipos de dados](cql.elements.md#cql.data-types).
1. Criar o espaço de chaves e a tabela de destino no Amazon Keyspaces.
1. Conecte-se ao Amazon Keyspaces usando `cqlsh` e substituindo o endpoint do serviço, o nome de usuário e a senha no exemplo a seguir por seus próprios valores.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Crie um novo espaço de chave com o nome `catalog` mostrado no exemplo a seguir.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Quando o novo espaço de chave estiver disponível, use o código a seguir para criar a tabela `book_awards` de destino.
```
CREATE TABLE "catalog.book_awards" (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Se o Apache Cassandra for sua fonte de dados original, uma maneira simples de criar a tabela de destino do Amazon Keyspaces com cabeçalhos correspondentes é gerar a instrução `CREATE TABLE` a partir da tabela de origem, conforme mostrado na instrução a seguir.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Em seguida, crie a tabela de destino no Amazon Keyspaces com os nomes das colunas e os tipos de dados correspondentes à descrição da tabela de origem do Cassandra.
# Etapa 2: Preparar os dados de origem para um carregamento de dados bem-sucedido
Preparar os dados de origem para uma transferência eficiente é um processo de duas etapas. Primeiro, você randomiza os dados. Na segunda etapa, você analisa os dados para determinar os valores de parâmetros `cqlsh` apropriados e as configurações de tabela necessárias para garantir que o carregamento de dados teve sucesso.
**Randomizar os dados**
O comando `cqlsh COPY FROM` lê e grava dados na mesma ordem em que aparecem no arquivo CSV. Se você usar o comando `cqlsh COPY TO` para criar o arquivo de origem, os dados serão gravados em ordem de classificação por chave no CSV. Internamente, o Amazon Keyspaces particiona os dados usando chaves de partição. Embora o Amazon Keyspaces tenha uma lógica integrada para ajudar a balancear a carga de solicitações para a mesma chave de partição, carregar os dados é mais rápido e eficiente se você randomizar o pedido. Isso ocorre porque você pode aproveitar o balanceamento de carga incorporado que ocorre quando o Amazon Keyspaces está gravando em partições diferentes.
Para distribuir uniformemente as gravações pelas partições, você deve randomizar os dados no arquivo de origem. Você pode escrever um aplicativo para fazer isso ou usar uma ferramenta de código aberto, como o [Shuf](https://en.wikipedia.org/wiki/Shuf). O Shuf está disponível gratuitamente em distribuições do Linux, no macOS (instalando coreutils no [homebrew](https://brew.sh)) e no Windows (usando o Subssistema Windows para Linux (WSL)). É necessária uma etapa extra para evitar que a linha do cabeçalho com os nomes das colunas sejam embaralhados nessa etapa.
Para randomizar o arquivo de origem enquanto preserva o cabeçalho, insira o código a seguir.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
O Shuf reescreve os dados em um novo arquivo CSV chamado `keyspace.table.csv`. Agora você pode excluir o arquivo `keyspaces_sample_table.csv` — ele não é mais necessário.
**Analisar os dados**
Determine o tamanho médio e máximo da linha analisando os dados.
Você pode fazer isso pelas seguintes razões:
+ O tamanho médio da linha ajuda a estimar a quantidade total de dados a serem transferidos.
+ Você precisa do tamanho médio da linha para provisionar a capacidade de gravação necessária para o upload dos dados.
+ Você pode garantir que cada linha tenha menos de 1 MB, que é o tamanho máximo da linha no Amazon Keyspaces.
**nota**
Essa cota se refere ao tamanho da linha, não ao tamanho da partição. Diferentemente das partições do Apache Cassandra, as partições do Amazon Keyspaces podem ser virtualmente desvinculadas em tamanho. As chaves de partição e as colunas de clustering exigem armazenamento adicional para metadados, que você deve adicionar ao tamanho bruto das linhas. Para obter mais informações, consulte [Estimar o tamanho da linha no Amazon Keyspaces](calculating-row-size.md).
O código a seguir usa [AWK](https://en.wikipedia.org/wiki/AWK) para analisar um arquivo CSV e imprimir o tamanho médio e máximo da linha.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
A execução desse código resulta na saída a seguir.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Você usa o tamanho médio da linha na próxima etapa deste tutorial para provisionar a capacidade de gravação da tabela.
# Etapa 3: definir a capacidade de throughput da tabela
Este tutorial mostra como ajustar o cqlsh para carregar dados em um intervalo de tempo definido. Como você sabe com antecedência quantas leituras e gravações você executa, use o modo de capacidade provisionada. Depois de concluir a transferência de dados, você deve definir o modo de capacidade da tabela de acordo com os padrões de tráfego do seu aplicativo. Para saber mais sobre gerenciamento de capacidade, consulte [Como gerenciar os recursos de tecnologia sem servidor no Amazon Keyspaces (para Apache Cassandra)](serverless_resource_management.md).
Com o modo de capacidade provisionada, você especifica com antecedência quanta capacidade de leitura e gravação deseja provisionar para sua tabela. A capacidade de gravação é cobrada por hora e medida em unidades de capacidade de gravação ()WCUs. Cada WCU tem capacidade de gravação suficiente para suportar a gravação de 1 KB de dados por segundo. Quando você carrega os dados, a taxa de gravação deve estar abaixo do máximo WCUs (parâmetro:`write_capacity_units`) definido na tabela de destino.
Por padrão, você pode provisionar até 40.000 WCUs em uma tabela e 80.000 WCUs em todas as tabelas da sua conta. Se precisar aumentar a capacidade, solicite um aumento de cota no console [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Para obter mais informações sobre cotas, consulte [Cotas para Amazon Keyspaces (para Apache Cassandra)](quotas.md).
**Calcule o número médio WCUs necessário para uma inserção**
A inserção de 1 KB de dados por segundo exige 1 WCU. Se o arquivo CSV tiver 360.000 linhas e você quiser carregar todos os dados em 1 hora, deverá gravar 100 linhas por segundo (360.000 linhas / 60 minutos / 60 segundos = 100 linhas por segundo). Se cada linha tiver até 1 KB de dados, para inserir 100 linhas por segundo, você deverá WCUs provisionar 100 para sua tabela. Se cada linha tiver 1,5 KB de dados, você precisará de duas WCUs para inserir uma linha por segundo. Portanto, para inserir 100 linhas por segundo, você deve provisionar 200 WCUs.
Para determinar quantas linhas WCUs você precisa inserir por segundo, divida o tamanho médio da linha em bytes por 1024 e arredonde para o número inteiro mais próximo.
Por exemplo, se o tamanho médio da linha for 3000 bytes, você precisará de três WCUs para inserir uma linha por segundo.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Calcule o tempo e a capacidade de carregamento de dados**
Agora que você sabe o tamanho médio e o número de linhas em seu arquivo CSV, você pode calcular quantas WCUs são necessárias para carregar os dados em um determinado período de tempo e o tempo aproximado necessário para carregar todos os dados em seu arquivo CSV usando diferentes configurações de WCU.
Por exemplo, se cada linha em seu arquivo tiver 1 KB e você tiver 1.000.000 de linhas em seu arquivo CSV, para carregar os dados em 1 hora, você precisará provisionar pelo menos 278 WCUs para sua tabela nessa hora.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Defina as configurações de capacidade provisionada**
Você pode definir as configurações de capacidade de gravação de uma tabela ao criar a tabela ou usando o comando CQL `ALTER TABLE`. A seguir está a sintaxe para alterar as configurações de capacidade provisionada de uma tabela com o comando CQL `ALTER TABLE`.
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Para obter a referência completa da linguagem, consulte [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Etapa 4: Definir configurações de `cqlsh COPY FROM`
Esta seção descreve como determinar os valores dos parâmetros de `cqlsh COPY FROM`. O comando `cqlsh COPY FROM` lê o arquivo CSV que você preparou anteriormente e insere os dados no Amazon Keyspaces usando CQL. O comando divide as linhas e distribui as operações `INSERT` entre um conjunto de operadores. Cada operador estabelece uma conexão com o Amazon Keyspaces e envia solicitações `INSERT` por esse canal.
O comando `cqlsh COPY` não tem lógica interna para distribuir o trabalho uniformemente entre seus operadores. No entanto, você pode configurá-lo manualmente para garantir que o trabalho seja distribuído uniformemente. Comece revisando esses principais parâmetros do cqlsh:
+ **DELIMITADOR**: se você usou um delimitador diferente de uma vírgula, você pode definir esse parâmetro, cujo padrão é vírgula.
+ **INGESTRATE**: o número alvo de linhas que `cqlsh COPY FROM` tenta processar por segundo. Se não especificado, o padrão será 100.000.
+ **NUMPROCESSES**: o número de processos do operador secundário que o cqlsh cria para tarefas `COPY FROM`. O máximo para essa configuração é 16, o padrão é `num_cores - 1`, onde `num_cores` é o número de núcleos de processamento no host executando cqlsh.
+ **MAXBATCHSIZE**: o tamanho do lote determina o número máximo de linhas inseridas na tabela de destino em um único lote. Se não for definido, o cqlsh usa lotes de 20 linhas inseridas.
+ **CHUNKSIZE**: o tamanho da unidade de trabalho que passa para o operador secundário. Por padrão, ele é definido como 5.000.
+ **MAXATTEMPTS**: o número máximo de novas tentativas de um bloco de operadores com falha. Depois que a tentativa máxima é atingida, os registros com falha são gravados em um novo arquivo CSV que você pode executar novamente depois de investigar a falha.
Defina `INGESTRATE` com base no número do WCUs que você provisionou para a tabela de destino de destino. O `INGESTRATE` do comando `cqlsh COPY FROM` não é um limite, é uma média de destino. Isso significa que ele pode (e geralmente acontece) ultrapassar o número que você definiu. Para permitir picos e garantir que haja capacidade suficiente para lidar com as solicitações de carregamento de dados, defina `INGESTRATE` como 90% da capacidade de gravação da tabela.
```
INGESTRATE = WCUs * .90
```
Em seguida, defina o parâmetro `NUMPROCESSES` como igual a um a menos que o número de núcleos em seu sistema. Para descobrir qual é o número de núcleos do seu sistema, você pode executar o código a seguir.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
Neste tutorial, use o valor a seguir.
```
NUMPROCESSES = 4
```
Cada processo cria um operador e cada operador estabelece uma conexão com o Amazon Keyspaces. O Amazon Keyspaces pode suportar até 3.000 solicitações de CQL por segundo em cada conexão. Isso significa que você precisa garantir que cada operador esteja processando menos de 3.000 solicitações por segundo.
Assim como `INGESTRATE`, os operadores geralmente ultrapassam o número definido e não são limitados pelos segundos do relógio. Portanto, para contabilizar as intermitências, defina seus parâmetros de cqlsh para que cada operador processe 2.500 solicitações por segundo. Para calcular a quantidade de trabalho distribuída a um operador, use a seguinte diretriz.
+ Divida `INGESTRATE` por `NUMPROCESSES`.
+ Se `INGESTRATE` / `NUMPROCESSES` > 2.500, diminua `INGESTRATE` para tornar essa fórmula verdadeira.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
Antes de definir as configurações para otimizar o upload de nossos dados de amostra, vamos analisar as configurações padrão `cqlsh` e ver como o uso delas afeta o processo de carregamento de dados. Como `cqlsh COPY FROM` usa o `CHUNKSIZE` para criar blocos do trabalho (instruções `INSERT`) para distribuir aos operadores, o trabalho não é automaticamente distribuído uniformemente. Alguns operadores podem ficar ociosos, dependendo da configuração de `INGESTRATE`.
Para distribuir o trabalho uniformemente entre os operadores e manter cada operador na taxa ideal de 2.500 solicitações por segundo, você deve definir `CHUNKSIZE`, `MAXBATCHSIZE` e `INGESTRATE` alterando os parâmetros de entrada. Para otimizar a utilização do tráfego de rede durante o carregamento de dados, escolha um valor para `MAXBATCHSIZE` próximo ao valor máximo de 30. Ao mudar `CHUNKSIZE` para 100 e `MAXBATCHSIZE` para 25, as 10.000 linhas são distribuídas uniformemente entre os quatro operadores (10.000/2.500 = 4).
O exemplo de código a seguir ilustra isso.
```
INGESTRATE = 10,000
NUMPROCESSES = 4
CHUNKSIZE = 100
MAXBATCHSIZE. = 25
Work Distribution:
Connection 1 / Worker 1 : 2,500 Requests per second
Connection 2 / Worker 2 : 2,500 Requests per second
Connection 3 / Worker 3 : 2,500 Requests per second
Connection 4 / Worker 4 : 2,500 Requests per second
```
Para resumir, use as seguintes fórmulas ao definir os parâmetros de `cqlsh COPY FROM`:
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1 (padrão)
+ **INGESTRATE/NUMPROCESSES** = 2.500 (Essa deve ser uma afirmação verdadeira.)
+ **MAXBATCHSIZE** = 30 (O padrão é 20. O Amazon Keyspaces aceita lotes de até 30.)
+ **CHUNKSIZE** = (INGESTRATE / NUMPROCESSES) / MAXBATCHSIZE
Agora que você calculou `NUMPROCESSES`, `INGESTRATE` e `CHUNKSIZE`, você está pronto para carregar seus dados.
# Etapa 5: Executar o comando `cqlsh COPY FROM` para carregar dados do arquivo CSV para a tabela de destino
Conclua as etapas a seguir para executar o comando `cqlsh COPY FROM`.
1. Conecte-se ao Amazon Keyspaces usando cqlsh.
1. Escolha seu espaço de chave com o código a seguir.
```
USE catalog;
```
1. Defina a consistência de gravação como `LOCAL_QUORUM`. Para garantir a durabilidade dos dados, o Amazon Keyspaces não permite outras configurações de consistência de gravação. Consulte o código a seguir.
```
CONSISTENCY LOCAL_QUORUM;
```
1. Prepare sua sintaxe `cqlsh COPY FROM` usando o exemplo de código a seguir.
```
COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true
AND INGESTRATE=calculated ingestrate
AND NUMPROCESSES=calculated numprocess
AND MAXBATCHSIZE=20
AND CHUNKSIZE=calculated chunksize;
```
1. Execute a instrução preparada na etapa anterior. O cqlsh reproduz todas as configurações que você definiu.
1. Verifique se as configurações correspondem à entrada. Veja o exemplo a seguir.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. Verifique o número de linhas transferidas e a taxa média atual, conforme mostrado no exemplo a seguir.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. Quando o cqlsh terminar de carregar os dados, revise o resumo das estatísticas de carregamento de dados (o número de arquivos lidos, o runtime e as linhas ignoradas), conforme mostrado no exemplo a seguir.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
Nesta etapa final do tutorial, você fez o upload dos dados para o Amazon Keyspaces.
**Importante**
Agora que você transferiu seus dados, ajuste as configurações do modo de capacidade da tabela de destino para corresponder aos padrões de tráfego regulares do seu aplicativo. Você incorre em cobranças de acordo com a taxa horária de sua capacidade provisionada até alterá-la.
# Solução de problemas
Depois que o upload dos dados for concluído, verifique se as linhas foram ignoradas. Para fazer isso, navegue até o diretório de origem do arquivo CSV de origem e pesquise um arquivo com o nome a seguir.
```
import_yourcsvfilename.err.timestamp.csv
```
O cqlsh grava todas as linhas de dados ignoradas em um arquivo com esse nome. Se o arquivo existir em seu diretório de origem e tiver dados nele, essas linhas não foram carregadas no Amazon Keyspaces. Para repetir essas linhas, primeiro verifique se há erros encontrados durante o upload e ajuste os dados adequadamente. Para repetir essas linhas, você pode executar o processo novamente.
**Erros comuns**
Os motivos mais comuns pelos quais as linhas não são carregadas são erros de capacidade e erros de análise.
**Erros de solicitação inválidos ao fazer o upload de dados para o Amazon Keyspaces**
No exemplo a seguir, a tabela de origem contém uma coluna de contador, que resulta em chamadas em lote registradas do comando cqlsh `COPY`. As chamadas em lote registradas não são compatíveis com o Amazon Keyspaces.
```
Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25
```
Para resolver esse erro, use DSBulk para migrar os dados. Para obter mais informações, consulte [Tutorial: Carregando dados no Amazon Keyspaces usando DSBulk](dsbulk-upload.md).
**Erros do analisador ao fazer o upload de dados para o Amazon Keyspaces**
O exemplo a seguir mostra uma linha ignorada devido a `ParseError`.
```
Failed to import 1 rows: ParseError - Invalid ... –
```
Para resolver esse erro, você precisa garantir que os dados a serem importados correspondam ao esquema da tabela no Amazon Keyspaces. Verifique se há erros de análise no arquivo de importação. Você pode tentar usar uma única linha de dados usando uma instrução `INSERT` para isolar o erro.
**Erros de capacidade ao fazer o upload de dados para o Amazon Keyspaces**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
O Amazon Keyspaces usa as exceções `ReadTimeout` e `WriteTimeout` para indicar quando uma solicitação de gravação falha devido à capacidade de throughput insuficiente. Para ajudar a diagnosticar exceções de capacidade insuficiente, o Amazon Keyspaces publica `WriteThrottleEvents` uma métrica na Amazon. `ReadThrottledEvents` CloudWatch Para obter mais informações, consulte [Monitorando o Amazon Keyspaces com a Amazon CloudWatch](monitoring-cloudwatch.md).
**Erros de cqlsh ao fazer upload de dados para o Amazon Keyspaces**
Para ajudar a solucionar erros de cqlsh, execute novamente o comando com falha com o sinalizador `--debug`.
Ao usar uma versão incompatível do cqlsh, você vê o seguinte erro.
```
AttributeError: 'NoneType' object has no attribute 'is_up'
Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts
```
Confirme se a versão correta do cqlsh foi instalada executando o comando a seguir.
```
cqlsh --version
```
Você deve ver algo parecido com a saída a seguir.
```
cqlsh 5.0.1
```
Se estiver usando o Windows, substitua todas as instâncias de `cqlsh` por `cqlsh.bat`. Por exemplo, para verificar a versão do cqlsh no Windows, execute o comando a seguir.
```
cqlsh.bat --version
```
A conexão com o Amazon Keyspaces falha depois que o cliente cqlsh recebe três erros consecutivos de qualquer tipo do servidor. O cliente cqlsh falha com a seguinte mensagem.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
Para resolver esse erro, você precisa garantir que os dados a serem importados correspondam ao esquema da tabela no Amazon Keyspaces. Verifique se há erros de análise no arquivo de importação. Você pode tentar usar uma única linha de dados usando uma instrução INSERT para isolar o erro.
O cliente tenta automaticamente restabelecer a conexão.
# Tutorial: Carregando dados no Amazon Keyspaces usando DSBulk
Este step-by-step tutorial orienta você na migração de dados do Apache Cassandra para o Amazon Keyspaces usando o Bulk Loader () DataStax disponível em. DSBulk [GitHub](https://github.com/datastax/dsbulk.git) DSBulk O uso é útil para fazer upload de conjuntos de dados para o Amazon Keyspaces para fins acadêmicos ou de teste. Para obter mais informações sobre como migrar workloads de produção, consulte [Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md). Neste tutorial, você concluirá as seguintes etapas.
Pré-requisitos — Configure uma AWS conta com credenciais, crie um arquivo de armazenamento confiável JKS para o certificado, configure, baixe `cqlsh` DSBulk, instale e configure um arquivo. `application.conf`
1. **Crie CSV de origem e tabela de destino**: prepare um arquivo CSV como dados de origem e crie o keyspace e a tabela de destino no Amazon Keyspaces.
1. **Prepare os dados**: randomize os dados no arquivo CSV e analise-os para determinar os tamanhos médio e máximo das linhas.
1. **Defina a capacidade de taxa de transferência** — calcule as unidades de capacidade de gravação necessárias (WCUs) com base no tamanho dos dados e no tempo de carregamento desejado, e configure a capacidade provisionada da tabela.
1. ** DSBulk Definir configurações** — Crie um arquivo de DSBulk configuração com configurações como autenticação, SSL/TLS, nível de consistência e tamanho do pool de conexão.
1. **Execute o comando DSBulk load** — Execute o comando DSBulk load para carregar os dados do arquivo CSV para a tabela do Amazon Keyspaces e monitorar o progresso.
**Topics**
+ [Pré-requisitos: etapas que você precisa concluir antes de fazer o upload de dados com DSBulk](dsbulk-upload-prequs.md)
+ [Etapa 1: Crie o arquivo CSV de origem e uma tabela de destino para o upload de dados usando DSBulk](dsbulk-upload-source.md)
+ [Etapa 2: Prepare os dados para upload usando DSBulk](dsbulk-upload-prepare-data.md)
+ [Etapa 3: definir a capacidade de throughput da tabela de destino](dsbulk-upload-capacity.md)
+ [Etapa 4: definir as configurações de `DSBulk` para carregar dados do arquivo CSV para a tabela de destino](dsbulk-upload-config.md)
+ [Etapa 5: Executar o comando DSBulk `load` para carregar dados do arquivo CSV para a tabela de destino](dsbulk-upload-run.md)
# Pré-requisitos: etapas que você precisa concluir antes de fazer o upload de dados com DSBulk
É necessário concluir as tarefas a seguir antes de iniciar este tutorial.
1. Se você ainda não fez isso, inscreva-se em uma AWS conta seguindo as etapas em[Conf AWS Identity and Access Management iguração](accessing.md#SettingUp.IAM).
1. Crie credenciais seguindo as etapas em [Crie e configure AWS credenciais para o Amazon Keyspaces](access.credentials.md).
1. Crie um arquivo JKS de armazenamento confiável.
1. Faça o download dos seguintes certificados digitais e salve os arquivos localmente ou em seu diretório pessoal.
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield Class 2 Root (opcional — para compatibilidade com versões anteriores)
Para baixar os certificados, você pode usar os seguintes comandos.
```
curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem
curl -O https://certs.secureserver.net/repository/sf-class2-root.crt
```
**nota**
O Amazon Keyspaces usava anteriormente certificados TLS ancorados na CA Starfield Class 2. AWS está migrando tudo Regiões da AWS para certificados emitidos pelo Amazon Trust Services (Amazon Root CAs 1—4). Durante essa transição, configure os clientes para que confiem tanto na Amazon Root CAs 1—4 quanto na raiz Starfield para garantir a compatibilidade em todas as regiões.
1. Converta os certificados digitais em arquivos TrustStore e adicione-os ao keystore.
```
openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der
keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der
keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der
keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der
keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der
keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der
```
Na última etapa, você precisa criar uma senha para o armazenamento de chaves e confiar em cada certificado. O comando interativo tem a aparência a seguir.
```
Enter keystore password:
Re-enter new password:
Owner: CN=Amazon Root CA 1, O=Amazon, C=US
Issuer: CN=Amazon Root CA 1, O=Amazon, C=US
Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038
Certificate fingerprints:
SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y...
0010: 10 4E 0A 08 .N..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 2, O=Amazon, C=US
Issuer: CN=Amazon Root CA 2, O=Amazon, C=US
Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A
SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K
0010: 84 E3 66 52 ..fR
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 3, O=Amazon, C=US
Issuer: CN=Amazon Root CA 3, O=Amazon, C=US
Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E
SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4
Signature algorithm name: SHA256withECDSA
Subject Public Key Algorithm: 256-bit EC (secp256r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p...
0010: 19 B1 78 C0 ..x.
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 4, O=Amazon, C=US
Issuer: CN=Amazon Root CA 4, O=Amazon, C=US
Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE
SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92
Signature algorithm name: SHA384withECDSA
Subject Public Key Algorithm: 384-bit EC (secp384r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V....
0010: 6D 57 E5 81 mW..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034
Certificate fingerprints:
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
[OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US]
SerialNumber: [ 00]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
]
Warning:
The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
Trust this certificate? [no]: yes
Certificate was added to keystore
```
1. Configure a conexão shell do Cassandra Query Language (cqlsh) e confirme se você pode se conectar ao Amazon Keyspaces seguindo as etapas em [Usar `cqlsh` para se conectar ao Amazon Keyspaces](programmatic.cqlsh.md).
1. Baixe e instale DSBulk.
**nota**
A versão mostrada neste tutorial pode não ser a versão mais recente disponível. Antes de fazer o download DSBulk, verifique a [página de download do DataStax Bulk Loader](https://downloads.datastax.com/#bulk-loader) para obter a versão mais recente e atualize adequadamente o número da versão nos comandos a seguir.
1. Para fazer o download DSBulk, você pode usar o código a seguir.
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. Em seguida, descompacte o arquivo tar e adicione-o DSBulk ao seu`PATH`, conforme mostrado no exemplo a seguir.
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. Crie um `application.conf` arquivo para armazenar as configurações a serem usadas DSBulk. Você pode salvar o exemplo a seguir como `./dsbulk_keyspaces.conf`. Substitua `localhost` pelo ponto de contato do seu cluster Cassandra local se você não estiver no nó local, por exemplo, o nome DNS ou o endereço IP. Anote o nome e o caminho do arquivo, pois você precisará especificar isso posteriormente no comando `dsbulk load`.
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. Para ativar o suporte ao SigV4, baixe o `jar` arquivo sombreado [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)e coloque-o na DSBulk `lib` pasta, conforme mostrado no exemplo a seguir.
```
curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar
```
# Etapa 1: Crie o arquivo CSV de origem e uma tabela de destino para o upload de dados usando DSBulk
Neste tutorial, usamos um arquivo de valores separados por vírgula (CSV) com o nome `keyspaces_sample_table.csv` como arquivo de origem para a migração de dados. O arquivo de amostra fornecido contém algumas linhas de dados de uma tabela com o nome `book_awards`.
1. Criar o arquivo de origem. Você pode escolher uma das seguintes opções:
+ Baixe o arquivo CSV de amostra (`keyspaces_sample_table.csv`) contido no seguinte arquivo [samplemigration.zip](samples/samplemigration.zip). Descompacte o arquivo e anote o caminho até `keyspaces_sample_table.csv`.
+ Para preencher um arquivo CSV com seus próprios dados armazenados em um banco de dados Apache Cassandra, você pode preencher o arquivo CSV de origem usando `dsbulk unload`, conforme mostrado no exemplo a seguir.
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
Certifique-se de que o arquivo CSV criado atenda aos seguintes requisitos:
+ A primeira linha contém os nomes das colunas.
+ Os nomes das colunas no arquivo CSV de origem correspondem aos nomes das colunas na tabela de destino.
+ Os dados são delimitados por uma vírgula.
+ Todos os valores de dados são tipos de dados válidos do Amazon Keyspaces. Consulte [Tipos de dados](cql.elements.md#cql.data-types).
1. Criar o espaço de chaves e a tabela de destino no Amazon Keyspaces.
1. Conecte-se ao Amazon Keyspaces usando `cqlsh` e substituindo o endpoint do serviço, o nome de usuário e a senha no exemplo a seguir por seus próprios valores.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Crie um novo espaço de chave com o nome `catalog` mostrado no exemplo a seguir.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Depois que o novo keyspace tiver o status de disponível, use o código a seguir para criar a tabela `book_awards` de destino. Para saber mais sobre a criação assíncrona de recursos e como verificar se um recurso está disponível, consulte [Verifique o status de criação do keyspace no Amazon Keyspaces](keyspaces-create.md).
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Se o Apache Cassandra for sua fonte de dados original, uma maneira simples de criar a tabela de destino do Amazon Keyspaces com cabeçalhos correspondentes é gerar a declaração `CREATE TABLE` a partir da tabela de origem, conforme mostrado na declaração a seguir.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Em seguida, crie a tabela de destino no Amazon Keyspaces com os nomes das colunas e os tipos de dados correspondentes à descrição da tabela de origem do Cassandra.
# Etapa 2: Prepare os dados para upload usando DSBulk
Preparar os dados de origem para uma transferência eficiente é um processo de duas etapas. Primeiro, você randomiza os dados. Na segunda etapa, você analisa os dados para determinar os valores de parâmetros `dsbulk` apropriados e as configurações de tabela necessárias.
**Randomizar os dados**
O comando `dsbulk` lê e grava dados na mesma ordem em que aparecem no arquivo CSV. Se você usar o comando `dsbulk` para criar o arquivo de origem, os dados serão gravados em ordem de classificação por chave no CSV. Internamente, o Amazon Keyspaces particiona os dados usando chaves de partição. Embora o Amazon Keyspaces tenha uma lógica integrada para ajudar a balancear a carga de solicitações para a mesma chave de partição, carregar os dados é mais rápido e eficiente se você randomizar o pedido. Isso ocorre porque você pode aproveitar o balanceamento de carga incorporado que ocorre quando o Amazon Keyspaces está gravando em partições diferentes.
Para distribuir uniformemente as gravações pelas partições, você deve randomizar os dados no arquivo de origem. Você pode escrever um aplicativo para fazer isso ou usar uma ferramenta de código aberto, como o [Shuf](https://en.wikipedia.org/wiki/Shuf). O Shuf está disponível gratuitamente em distribuições do Linux, no macOS (instalando coreutils no [homebrew](https://brew.sh)) e no Windows (usando o Subssistema Windows para Linux (WSL)). É necessária uma etapa extra para evitar que a linha do cabeçalho com os nomes das colunas sejam embaralhados nessa etapa.
Para randomizar o arquivo de origem enquanto preserva o cabeçalho, insira o código a seguir.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
O Shuf reescreve os dados em um novo arquivo CSV chamado `keyspace.table.csv`. Agora você pode excluir o arquivo `keyspaces_sample_table.csv` — ele não é mais necessário.
**Analisar os dados**
Determine o tamanho médio e máximo da linha analisando os dados.
Você pode fazer isso pelas seguintes razões:
+ O tamanho médio da linha ajuda a estimar a quantidade total de dados a serem transferidos.
+ Você precisa do tamanho médio da linha para provisionar a capacidade de gravação necessária para o upload dos dados.
+ Você pode garantir que cada linha tenha menos de 1 MB, que é o tamanho máximo da linha no Amazon Keyspaces.
**nota**
Essa cota se refere ao tamanho da linha, não ao tamanho da partição. Diferentemente das partições do Apache Cassandra, as partições do Amazon Keyspaces podem ser virtualmente desvinculadas em tamanho. As chaves de partição e as colunas de clustering exigem armazenamento adicional para metadados, que você deve adicionar ao tamanho bruto das linhas. Para obter mais informações, consulte [Estimar o tamanho da linha no Amazon Keyspaces](calculating-row-size.md).
O código a seguir usa [AWK](https://en.wikipedia.org/wiki/AWK) para analisar um arquivo CSV e imprimir o tamanho médio e máximo da linha.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
A execução desse código resulta na saída a seguir.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Certifique-se de que o tamanho máximo da linha não exceda 1 MB. Se isso acontecer, você precisará dividir a linha ou compactar os dados para reduzir o tamanho da linha para menos de 1 MB. Na próxima etapa deste tutorial, você usa o tamanho médio da linha para provisionar a capacidade de gravação da tabela.
# Etapa 3: definir a capacidade de throughput da tabela de destino
Este tutorial mostra como ajustar o carregamento DSBulk de dados dentro de um intervalo de tempo definido. Como você sabe com antecedência quantas leituras e gravações você executa, use o modo de capacidade provisionada. Depois de concluir a transferência de dados, você deve definir o modo de capacidade da tabela de acordo com os padrões de tráfego do seu aplicativo. Para saber mais sobre gerenciamento de capacidade, consulte [Como gerenciar os recursos de tecnologia sem servidor no Amazon Keyspaces (para Apache Cassandra)](serverless_resource_management.md).
Com o modo de capacidade provisionada, você especifica com antecedência quanta capacidade de leitura e gravação deseja provisionar para sua tabela. A capacidade de gravação é cobrada por hora e medida em unidades de capacidade de gravação ()WCUs. Cada WCU tem capacidade de gravação suficiente para suportar a gravação de 1 KB de dados por segundo. Quando você carrega os dados, a taxa de gravação deve estar abaixo do máximo WCUs (parâmetro:`write_capacity_units`) definido na tabela de destino.
Por padrão, você pode provisionar até 40.000 WCUs em uma tabela e 80.000 WCUs em todas as tabelas da sua conta. Se precisar aumentar a capacidade, solicite um aumento de cota no console [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Para obter mais informações sobre cotas, consulte [Cotas para Amazon Keyspaces (para Apache Cassandra)](quotas.md).
**Calcule o número médio WCUs necessário para uma inserção**
A inserção de 1 KB de dados por segundo exige 1 WCU. Se o arquivo CSV tiver 360.000 linhas e você quiser carregar todos os dados em 1 hora, deverá gravar 100 linhas por segundo (360.000 linhas / 60 minutos / 60 segundos = 100 linhas por segundo). Se cada linha tiver até 1 KB de dados, para inserir 100 linhas por segundo, você deverá WCUs provisionar 100 para sua tabela. Se cada linha tiver 1,5 KB de dados, você precisará de duas WCUs para inserir uma linha por segundo. Portanto, para inserir 100 linhas por segundo, você deve provisionar 200 WCUs.
Para determinar quantas linhas WCUs você precisa inserir por segundo, divida o tamanho médio da linha em bytes por 1024 e arredonde para o número inteiro mais próximo.
Por exemplo, se o tamanho médio da linha for 3000 bytes, você precisará de três WCUs para inserir uma linha por segundo.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Calcule o tempo e a capacidade de carregamento de dados**
Agora que você sabe o tamanho médio e o número de linhas em seu arquivo CSV, você pode calcular quantas WCUs são necessárias para carregar os dados em um determinado período de tempo e o tempo aproximado necessário para carregar todos os dados em seu arquivo CSV usando diferentes configurações de WCU.
Por exemplo, se cada linha em seu arquivo tiver 1 KB e você tiver 1.000.000 de linhas em seu arquivo CSV, para carregar os dados em 1 hora, você precisará provisionar pelo menos 278 WCUs para sua tabela nessa hora.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Defina as configurações de capacidade provisionada**
Você pode definir as configurações de capacidade de gravação de uma tabela ao criar a tabela ou usando o comando `ALTER TABLE`. A seguir está a sintaxe para alterar as configurações de capacidade provisionada de uma tabela com o comando `ALTER TABLE`.
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Para obter a referência completa do idioma, consulte [CRIAR TABELA](cql.ddl.table.md#cql.ddl.table.create) e [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Etapa 4: definir as configurações de `DSBulk` para carregar dados do arquivo CSV para a tabela de destino
Esta seção descreve as etapas necessárias para configurar o upload de dados DSBulk para o Amazon Keyspaces. Você configura DSBulk usando um arquivo de configuração. Você especifica o arquivo de configuração diretamente da linha de comando.
1. Crie um arquivo de DSBulk configuração para a migração para o Amazon Keyspaces. Neste exemplo, usamos o nome do arquivo. `dsbulk_keyspaces.conf` Especifique as seguintes configurações no arquivo DSBulk de configuração.
1. *`PlainTextAuthProvider`*: crie o provedor de autenticação com a classe `PlainTextAuthProvider`. `ServiceUserName` e `ServicePassword` devem corresponder ao nome de usuário e à senha que você obteve ao gerar as credenciais específicas do serviço seguindo as etapas em [Crie credenciais para acesso programático ao Amazon Keyspaces](programmatic.credentials.md).
1. *`local-datacenter`*— Defina o valor do `local-datacenter` ao Região da AWS qual você está se conectando. Por exemplo, se o aplicativo estiver se conectando a `cassandra.us-east-1.amazonaws.com`, defina o datacenter local como `us-east-1`. Para todos os disponíveis Regiões da AWS, consulte[Endpoints de serviço para Amazon Keyspaces](programmatic.endpoints.md). Para evitar réplicas, defina `slow-replica-avoidance` como `false`.
1. *`SSLEngineFactory`*: para configurar o SSL/TLS, inicialize o `SSLEngineFactory` adicionando uma seção no arquivo de configuração com uma única linha que especifica a classe com `class = DefaultSslEngineFactory`. Forneça o caminho para `cassandra_truststore.jks` e a senha que você criou anteriormente.
1. *`consistency`*: defina o nível de consistência como `LOCAL QUORUM`. Outros níveis de consistência de gravação não são compatíveis; para obter mais informações, consulte [Níveis de consistência de leitura e gravação do Apache Cassandra suportados e custos associados](consistency.md).
1. O número de conexões por grupo é configurável no driver Java. Para este exemplo, defina `advanced.connection.pool.local.size` como 3.
Veja a seguir o arquivo de configuração de exemplo completo.
```
datastax-java-driver {
basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"]
advanced.auth-provider {
class = PlainTextAuthProvider
username = "ServiceUserName"
password = "ServicePassword"
}
basic.load-balancing-policy {
local-datacenter = "us-east-1"
slow-replica-avoidance = false
}
basic.request {
consistency = LOCAL_QUORUM
default-idempotence = true
}
advanced.ssl-engine-factory {
class = DefaultSslEngineFactory
truststore-path = "./cassandra_truststore.jks"
truststore-password = "my_password"
hostname-validation = false
}
advanced.connection.pool.local.size = 3
}
```
1. Revise os parâmetros do DSBulk `load` comando.
1. *`executor.maxPerSecond`*: o número máximo de linhas que o comando load tenta processar simultaneamente por segundo. Se não for definida, essa configuração é desativada com -1.
Defina `executor.maxPerSecond` com base no número do WCUs que você provisionou para a tabela de destino de destino. O `executor.maxPerSecond` do comando `load` não é um limite – é uma média de destino. Isso significa que ele pode (e geralmente acontece) ultrapassar o número que você definiu. Para permitir picos e garantir que haja capacidade suficiente para lidar com as solicitações de carregamento de dados, defina `executor.maxPerSecond` como 90% da capacidade de gravação da tabela.
```
executor.maxPerSecond = WCUs * .90
```
Neste tutorial, definimos `executor.maxPerSecond` como 5.
**nota**
Se você estiver usando DSBulk 1.6.0 ou superior, poderá usar `dsbulk.engine.maxConcurrentQueries` em vez disso.
1. Configure esses parâmetros adicionais para o DSBulk `load` comando.
+ *`batch-mode`*: esse parâmetro instrui o sistema a agrupar as operações por chave de partição. Recomendamos desativar o modo em lote, pois isso pode resultar em cenários e causas de teclas de atalho `WriteThrottleEvents`.
+ *`driver.advanced.retry-policy-max-retries`*: isso determina quantas vezes tentar novamente uma consulta com falha. Se não estiver definido, o padrão é 10. Você pode ajustar esse valor conforme necessário.
+ *`driver.basic.request.timeout`* – O tempo em minutos em que o sistema espera o retorno de uma consulta. Se não estiver definido, o padrão é "5 minutos". Você pode ajustar esse valor conforme necessário.
# Etapa 5: Executar o comando DSBulk `load` para carregar dados do arquivo CSV para a tabela de destino
Na etapa final deste tutorial, você carrega os dados no Amazon Keyspaces.
Conclua as etapas a seguir para executar o comando DSBulk `load`.
1. Execute o código a seguir para fazer o upload dos dados do seu arquivo csv para a tabela do Amazon Keyspaces. Certifique-se de atualizar o caminho para o arquivo de configuração do aplicativo que você criou anteriormente.
```
dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards
```
1. A saída inclui a localização de um arquivo de log que detalha as operações bem-sucedidas e malsucedidas. O arquivo é armazenado no diretório a seguir.
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. As entradas do arquivo de log incluirão métricas, como no exemplo a seguir. Verifique se o número de linhas é consistente com o número de linhas em seu arquivo csv.
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**Importante**
Agora que você transferiu seus dados, ajuste as configurações do modo de capacidade da tabela de destino para corresponder aos padrões de tráfego regulares do seu aplicativo. Você incorre em cobranças de acordo com a taxa horária de sua capacidade provisionada até alterá-la. Para obter mais informações, consulte [Configurar modos de read/write capacidade no Amazon Keyspaces](ReadWriteCapacityMode.md).