Migrar do Aerospike para o Bigtable

Este documento orienta você no processo de migração de dados do Aerospike para o Bigtable. Ele descreve como usar ferramentas de código aberto, como a biblioteca do adaptador, para realizar a migração.

Antes de começar a migração, familiarize-se com o Bigtable para usuários do Aerospike.

Visão geral da migração

É possível migrar seus dados do Aerospike para o Bigtable com tempo de inatividade mínimo ou zero.

O diagrama a seguir descreve as etapas de migração:

O processo de migração do Aerospike para o Bigtable.
Figura 1. O processo de migração do Aerospike para o Bigtable (clique para ampliar)..
  1. Transmitir mudanças contínuas:replique atualizações contínuas do Aerospike para o Bigtable usando o conector de origem (saída) do Aerospike Kafka e o conector de coletor do Bigtable do Kafka Connect.
  2. Importar backup:crie um backup do Aerospike e importe-o para o Bigtable usando o job do Dataflow AerospikeBackupToBigtable.
  3. Realizar a transferência:mova o tráfego de aplicativos para o Bigtable.

Escopo e compatibilidade da migração

Como o Bigtable opera em bytes brutos em vez de contêineres digitados, o processo de migração envolve o mapeamento de recursos e funcionalidades do Aerospike para estruturas compatíveis do Bigtable. A biblioteca do adaptador fornece as ferramentas necessárias para alcançar a compatibilidade estrutural e resolver lacunas, como a serialização de objetos. No entanto, alguns recursos, como funções definidas pelo usuário (UDFs), não podem ser migrados devido a diferenças fundamentais entre os sistemas.

A tabela a seguir resume como o processo de migração processa os recursos do Aerospike.

Recurso Suporte Descrição
Arquitetura de memória híbrida (HMA) do Aerospike Com suporte Migrado para a camada de armazenamento SSD ou para a camada na memória. A edição Enterprise Plus do Bigtable oferece acesso ao armazenamento na memória para cargas de trabalho sensíveis à latência que exigem tempos de resposta abaixo do milissegundo, semelhantes ao desempenho do Aerospike.
Escalares (Int, Float, String, Bool) Com suporte Migrado para células do Bigtable.
Listas e mapas Com suporte Os mapas precisam ter chaves de string. Listas e mapas são serializados em colunas separadas pela biblioteca do adaptador.
Índices secundários Parcialmente compatível Não migrado diretamente. Precisa ser reimplementado como índices secundários assíncronos.
Tempo time to live (TTL) no nível do registro Com suporte Configurado no nível do grupo de colunas ou simulado por célula no Bigtable.
UDFs Indisponível A lógica personalizada do lado do servidor precisa ser movida para o aplicativo do lado do cliente.
HyperLogLog Indisponível Indisponível no processo de migração.
GeoJSON Indisponível Indisponível no processo de migração.
Chaves de registro Indisponível As chaves de registro não são migradas diretamente. Em vez disso, a migração usa o resumo do registro como a chave de linha.

Antes de começar

Antes de iniciar a migração, conclua as etapas preparatórias a seguir para reduzir o risco e garantir uma transição tranquila:

  • Validar seus dados:confirme se a implantação do Aerospike não depende de tipos de dados, índices secundários ou UDFs sem suporte. Como proteção, você pode importar um subconjunto representativo dos seus dados para o Bigtable e validar o design do esquema.
  • Provisionar infraestrutura:configure os serviços necessários para o pipeline de migração: Bigtable, Kafka e Kafka Connect.
    • Planejamento de capacidade: provisione o Bigtable com capacidade suficiente para processar a carga de trabalho esperada. Selecione uma região próxima ao cluster do Aerospike. Para orientações sobre como estimar os recursos necessários, consulte Noções básicas sobre o desempenho do Bigtable.
    • Camada de armazenamento: para cargas de trabalho que exigem tempos de resposta abaixo do milissegundo, considere usar a camada na memória do Bigtable. Essa camada armazena dados na RAM para oferecer o melhor desempenho para aplicativos com leitura intensa ou sensíveis à latência. Para mais informações, consulte Visão geral da camada na memória.
  • Configurar acesso e rede:atribua papéis apropriados do Identity and Access Management (IAM) e garanta a conectividade de rede.
  • Ativar o monitoramento e o relatório de erros:configure a observabilidade para o novo ambiente, incluindo registros, métricas e alertas.
  • Comparar o desempenho de referência:registre o desempenho atual do sistema para fornecer uma referência para validação após a migração.
  • Criar backups:crie um backup completo dos seus dados do Aerospike.
  • Executar uma migração de teste:valide a configuração em um ambiente de preparação antes de tentar uma migração de produção.

Migrar dados

Conclua as etapas a seguir para migrar seus dados do Aerospike para o Bigtable.

Iniciar o fluxo de alterações

Quando você ativa o fluxo de alterações do Aerospike, o conector de origem (saída) do Aerospike Kafka começa a publicar as atualizações de registro do Aerospike em um tópico do Kafka. Verifique se o Kafka tem capacidade de armazenamento suficiente para armazenar em buffer as mudanças e configure o conector para gerar dados no formato JSON.

Confira a seguir um exemplo de configuração do conector do Kafka:


  service:
    port: <port_to_run_on>

  producer-props:
    bootstrap.servers:
      - <kafka_host>

  format:
    mode: json
    metadata-key: metadata

  routing:
    mode: static
    destination: <kafka_topic>

A comunicação com o Kafka usando o conector de origem (saída) do Aerospike Kafka requer a replicação entre data centers (XDR, na sigla em inglês) do Aerospike, que replica de forma assíncrona as mudanças de cluster em links de latência mais alta. A XDR está disponível apenas na edição Enterprise do Aerospike. Se você usa a edição Community do Aerospike, mude para a edição Enterprise ou realize uma migração off-line usando apenas o job do Dataflow AerospikeBackupToBigtable.

Um exemplo de configuração para XDR no Aerospike é o seguinte:


  xdr {
      dc aerospike-kafka-source {
              connector true
              node-address-port <aerospike_connect_host> <aerospike_connect_port>
              namespace <your_namespace_to_replicate> {
              }
      }
  }

Exportar dados do Aerospike

Depois de iniciar o fluxo de alterações, gere um backup do conjunto de dados do Aerospike. Use a ferramenta de linha de comando asbackup para criar backups de um cluster de banco de dados do Aerospike. Algumas atualizações podem aparecer no backup e no fluxo de alterações, o que é esperado e não afeta a migração. Para permitir importações paralelas durante a restauração, divida os backups em vários arquivos.

Importar dados para o Bigtable

Para importar dados de backup para o Bigtable, faça o seguinte:

  1. Faça o upload do backup para um bucket do Cloud Storage.
  2. Execute o job do Dataflow AerospikeBackupToBigtable para importar o backup para o Bigtable. Se o backup for dividido em vários arquivos, o job os processará em paralelo. Para processar o aumento da carga de gravação e manter a capacidade de processamento ideal, provisione mais recursos do Bigtable.

Aplicar as atualizações de registro ao Bigtable

Depois de importar o backup para o Bigtable, aplique as atualizações de registro armazenadas em buffer no Kafka ao Bigtable usando o conector de coletor do Bigtable do Kafka Connect.

Traduzir mensagens para um formato compatível

As ferramentas de migração do Aerospike incluem o Replicator SMT, que é executado no Kafka Connect. O replicador traduz mensagens publicadas pelo conector de origem (saída) do Aerospike Kafka para um formato compatível com o coletor de destino que grava os registros no Bigtable. A tradução é necessária porque o coletor espera dados em um formato específico que difere de como o Aerospike transmite as mudanças.

A tabela a seguir ajuda a estimar os recursos de máquina necessários para alcançar uma determinada capacidade de processamento:

Estrutura do registro Capacidade de processamento Latência P99
Fixa Até 3.700 registros por segundo por vCPU 300 ms
Aninhado Até 2.600 registros por segundo por vCPU 300 ms

Essas estimativas pressupõem que os registros serializados em JSON tenham 1 KB de tamanho. O tempo de análise aumenta com a complexidade das estruturas de mensagens, o que significa que os objetos aninhados armazenados em registros do Aerospike levam mais tempo para serem analisados.

É possível usar a métrica consumer_lag para verificar quantas mensagens estão na fila de processamento e medir o atraso de replicação. Quando o coletor processa o backlog de mensagens no tópico, o atraso do consumidor diminui até se estabilizar perto de zero. Nesse momento, o coletor processa as atualizações do Aerospike quase em tempo real, preparando você para a transferência. É possível usar o sink-record-active-count para verificar o número de mensagens já processadas.

Ingerir mensagens com o conector de coletor do Bigtable do Kafka Connect

O conector de coletor do Bigtable do Kafka Connect ingere mensagens do Kafka para o Bigtable. Ao configurar o conector, defina insert.mode como REPLACE_IF_NEWEST para garantir que o registro gravado na linha de destino no Bigtable seja o mais recente. Para mais informações, consulte Configuração do conector de coletor do Bigtable do Kafka Connect.

A tabela a seguir fornece orientações sobre a latência introduzida e os recursos de computação necessários para diferentes cargas de trabalho:

Estrutura do registro Capacidade de processamento Latência P99
Fixa Até 3.700 registros por segundo por vCPU 74 ms
Aninhado Até 3.700 registros por segundo por vCPU 100 ms

Essas estimativas pressupõem que os registros serializados em JSON tenham 1 KB de tamanho. A latência informada é o tempo de processamento no coletor. Considere uma sobrecarga adicional para fazer uma solicitação de gravação no Bigtable de aproximadamente 600 ms.

Mudar para o Bigtable

Mude o aplicativo para usar o Bigtable como o banco de dados principal.

Para garantir a consistência de leitura das gravações, desligue temporariamente o aplicativo até que o atraso de replicação chegue a zero. Isso garante que nenhuma mutação seja perdida e que as leituras de dados reflitam o estado mais recente.

Por exemplo, uma mutação aplicada no Aerospike pouco antes da transferência pode não ser replicada no Bigtable ainda, causando leituras obsoletas. Para evitar esse cenário, mantenha o aplicativo off-line até que as métricas consumer_lag e sink-record-active-count cheguem a 0. Depois que todas as mudanças pendentes forem propagadas, reinicie o aplicativo com o Bigtable como o banco de dados principal.

Embora uma migração em tempo real possa evitar o tempo de inatividade, ela tem as seguintes restrições:

  • As mutações aplicadas no Bigtable não são replicadas de volta para o Aerospike.
  • As mutações originadas do Aerospike podem aparecer no Bigtable com um atraso.
  • Mutações atrasadas do Aerospike podem substituir atualizações mais recentes no Bigtable.

Verificar a implantação

Após a implantação, valide o desempenho do aplicativo revisando métricas como taxas de erro, latência e custo. Também é possível realizar verificações de integridade de dados.

Monitoramento e observabilidade

Monitore as seguintes métricas durante a migração:

  • Atraso total: calculado como o atraso do consumidor do Kafka mais o sink-record-active-count. Essas métricas indicam o quanto o Bigtable está atrasado em relação ao Aerospike. Um valor de atraso estável é necessário antes de redirecionar o tráfego para o Bigtable.
  • Utilização de CPU e memória: monitore a utilização de CPU e memória de todos os componentes do pipeline de fluxo de alterações.
  • Capacidade de armazenamento do Kafka: monitore a capacidade de implantações do Kafka autogerenciadas. Se o armazenamento ficar cheio, novos eventos não poderão ser armazenados em buffer, causando falha na migração.
  • Taxas de erro do aplicativo: monitore as taxas de erro e as saídas de erro de todos os elementos do pipeline de fluxo de alterações.

Limitações

As seções a seguir descrevem as limitações a serem consideradas ao migrar dados do Aerospike para o Bigtable.

Consistência de dados durante a migração

Quando você usa a ferramenta asbackup para gerar o backup do Aerospike, os registros modificados durante o processo de backup podem ser excluídos porque o processo de backup não oferece suporte a backups atômicos. Essa limitação não afeta a correção porque todas as mudanças aparecem no fluxo de alterações.

Durante a importação do backup para o Bigtable, cada linha é gravada com um carimbo de data/hora da última atualização (LUT, na sigla em inglês) de 0. As atualizações do fluxo de alterações são aplicadas sobre o backup importado. As linhas gravadas do fluxo usam o valor da LUT como o carimbo de data/hora da linha do Bigtable. A configuração do coletor faz com que a atualização com um carimbo de data/hora mais recente substitua um mais antigo. Isso garante que qualquer mudança reproduzida do fluxo substitua a linha correspondente.

Uso da LUT

O processo de migração usa o Aerospike XDR para replicar mudanças e depende da LUT para resolução de conflitos. Como as LUTs são baseadas no relógio do sistema do nó, elas podem não ser estritamente monotônicas. Como resultado, um registro desatualizado pode ocasionalmente ter uma LUT mais recente e substituir um registro mais recente. Além disso, o conector de origem (saída) do Aerospike Kafka pode não preservar a ordem exata das mensagens ao publicar no Kafka. Como resultado, a LUT serve como o marcador de versão autoritativo, garantindo que apenas os registros com a LUT mais recente sejam aplicados ao Bigtable.

Se um registro for atualizado depois que você iniciar o fluxo de alterações, mas antes de gerar o backup, o backup poderá capturar a versão mais recente, enquanto o fluxo contém uma versão mais antiga. Essa versão mais antiga pode substituir temporariamente a mais recente. No entanto, quando o evento de fluxo subsequente com a LUT correta chegar, a versão mais recente será restaurada. Para evitar inconsistências, aguarde a estabilização da replicação e a mensagem não processada mais antiga no pipeline ser mais recente que o backup.

Validação de dados

O pipeline de migração não realiza a soma de verificação de dados em trânsito. Se você precisar de verificações de integridade de dados de ponta a ponta, implemente a validação.

Solução de problemas

As seções a seguir descrevem erros comuns que podem ocorrer durante o processo de migração e fornecem orientações sobre como resolvê-los.

Erros de importação de backup

Durante a importação do backup do Aerospike para o Bigtable, você pode encontrar os seguintes erros:

Tipo de erro Causa Solução
Arquivo de backup corrompido Os arquivos de backup não podem ser lidos ou contêm registros corrompidos. O job de importação falha. Inspecione os arquivos afetados em busca de problemas de integridade. Se não for possível recuperar, gere um novo backup e repita a importação.
Falhas de gravação do Bigtable Ocorrem problemas de conectividade ou serviço do Bigtable. A importação não falha. Os registros com falha são exportados para um arquivo de saída de erro no formato JSON. Reaplique-os manualmente ou tente novamente o job de importação completo.
Dados não compatíveis O backup contém entradas que não podem ser importadas para o Bigtable. A importação não falha. Dados sem suporte, como UDFs, são informados como avisos nos registros de jobs. Revise os registros para verificar as entradas sem suporte.

Depois que a importação do backup for concluída e os registros inválidos forem resolvidos, você poderá aplicar o fluxo de alterações.

Erros de fluxo de alterações

Durante a aplicação do fluxo de alterações, falhas podem ocorrer nos seguintes níveis:

  • Erros do Replicator SMT:o SMT não consegue transformar os dados produzidos pelo Aerospike.
  • Erros de coletor:os eventos não podem ser aplicados ao Bigtable.

Em ambos os casos, os eventos com falha são redirecionados para um tópico dedicado do Kafka. É possível registrar os eventos para auditoria ou processá-los usando uma lógica de recuperação personalizada.

A seguir