Práticas recomendadas de carregamento em massa

Nesta página, apresentamos diretrizes para o carregamento eficiente em massa de grandes quantidades de dados no Spanner.

Existem várias opções para carregar dados em massa no Spanner:

Embora seja possível inserir linhas usando a Google Cloud CLI, não recomendamos o uso da CLI gcloud para carregamento em massa.

Diretrizes de desempenho para carregamento em massa

Para ter o desempenho ideal de carregamento em massa, maximize o uso do particionamento para distribuir a gravação dos dados nas tarefas do worker.

O Spanner usa a divisão baseada em carga para distribuir uniformemente a carga de dados entre os recursos de computação da instância. Após alguns minutos de alta carga, o Spanner introduz limites divididos entre as linhas. Em geral, se o carregamento de dados estiver bem distribuído e você seguir as práticas recomendadas para o design do esquema e o carregamento em massa, a capacidade de gravação dobrará a cada poucos minutos até saturar os recursos disponíveis da CPU na instância.

Particionar os dados por chave primária

O Spanner particiona automaticamente as tabelas em intervalos menores. A chave primária de uma linha determina onde ela é particionada.

Para conseguir a capacidade ideal de gravação para cargas em massa, particione os dados por chave primária com este padrão:

  • Cada partição contém um intervalo de linhas consecutivas, conforme determinado pelas colunas-chave.
  • Cada confirmação contém dados para apenas uma única partição.

Recomendamos que o número de partições seja 10 vezes o número de nós na instância do Spanner. Para atribuir linhas a partições, faça o seguinte:

  • Classifique os dados por chave primária.
  • Divida os dados em 10 * (número de nós) partições separadas e com tamanhos iguais.
  • Crie e atribua uma tarefa de worker separada para cada partição. Isso é feito no aplicativo Ele não é um recurso do Spanner.

Seguindo esse padrão, você verá uma capacidade máxima geral de gravação em massa de 10 a 20 MB por segundo por nó para cargas grandes.

À medida que os dados são carregados, o Spanner cria e atualiza divisões para equilibrar a carga nos nós na instância. Durante esse processo, pode ocorrer uma queda temporária na capacidade.

Exemplo

Você tem uma configuração regional com 3 nós e 90.000 linhas em uma tabela não intercalada. As chaves primárias no intervalo da tabela variam de 1 a 90.000.

  • Linhas: 90.000
  • Nós: 3
  • Partições: 10 * 3 = 30
  • Linhas por partição: 90000 / 30 = 3000.

A primeira partição inclui o intervalo de chaves de 1 a 3000. A segunda inclui o intervalo de chaves 3001 a 6000. A 30ª partição inclui o intervalo de chaves 87001 a 90000. Não use chaves sequenciais em uma tabela grande. Este exemplo é apenas para demonstração.

Cada tarefa de worker envia as gravações para uma única partição. Dentro de cada uma delas, grave as linhas sequencialmente pela chave primária. Gravar linhas de forma aleatória, com relação à chave primária, também fornecerá uma capacidade consideravelmente alta. A medição das execuções de teste fornecerá um insight sobre qual abordagem fornece o melhor desempenho para o conjunto de dados.

Carga em massa sem particionamento

Gravar um conjunto contínuo de linhas em uma confirmação pode ser mais rápido do que gravar linhas aleatórias. As linhas aleatórias também podem incluir dados de partições diferentes.

Quando mais partições são gravadas em um commit, é necessária mais coordenação entre os servidores, aumentando a latência e a sobrecarga do commit.

Várias partições provavelmente estão envolvidas, porque cada linha aleatória pode pertencer a uma partição diferente. Na pior das hipóteses, cada gravação envolve todas as partições na instância do Spanner. Conforme mencionado anteriormente, a capacidade de gravação é diminuída quando mais partições estão envolvidas.

Evite a sobrecarga

É possível enviar mais solicitações de gravação do que o Spanner consegue processar. O Spanner processa a sobrecarga abortando transações, o que é chamado de pushback. Para transações somente gravação, o Spanner repete a transação automaticamente. Nesses casos, o pushback aparece como alta latência. Durante cargas pesadas, ele pode levar até um minuto. Durante cargas muito pesadas, o pushback pode durar vários minutos. Para evitar o pushback, limite os pedidos de gravação para manter a utilização da CPU dentro de limites razoáveis. Como alternativa, os usuários podem aumentar o número de nós para que a utilização da CPU fique dentro dos limites.

Confirmação entre 1 MB e 5 MB de mutações por vez

Cada gravação no Spanner contém algumas sobrecargas, seja ela grande ou pequena. Para maximizar a capacidade, aumente a quantidade de dados armazenados por gravação. Gravações maiores diminuem a taxa de sobrecarga por gravação. Uma boa técnica é que cada confirmação faça mutação de centenas de linhas. Ao gravar linhas relativamente grandes, um tamanho de confirmação de 1 MB a 5 MB geralmente fornece o melhor desempenho. Ao gravar valores pequenos ou indexados, normalmente é melhor gravar, no máximo, algumas centenas de linhas em uma única confirmação. Independentemente do tamanho da confirmação e do número de linhas, há uma limitação de 80.000 mutações por confirmação. Para determinar o desempenho ideal, teste e meça a capacidade.

Confirmações maiores que 5 MB ou mais do que algumas centenas de linhas não oferecem benefícios extras. Além disso, correm o risco de exceder os limites do Spanner no tamanho da confirmação e nas mutações por confirmação.

Diretrizes para índices secundários

Se o banco de dados tiver índices secundários, escolha entre adicionar os índices ao esquema do banco de dados antes ou depois de carregar os dados da tabela.

  • Adicionar o índice antes do carregamento dos dados permite que a alteração do esquema seja concluída imediatamente. No entanto, cada gravação que afeta o índice leva mais tempo, pois também precisa atualizá-lo. Quando o carregamento de dados é concluído, o banco de dados é imediatamente utilizável com todos os índices em vigor. Para criar uma tabela e os índices ao mesmo tempo, envie as instruções DDL para a nova tabela e os novos índices em uma única solicitação para o Spanner.

  • Adicionar o índice depois de carregar os dados significa que cada gravação é eficiente. No entanto, a alteração do esquema para cada preenchimento de índice pode levar muito tempo. O banco de dados não é totalmente utilizável, e as consultas não podem usar os índices até que todas as alterações de esquema sejam concluídas. O banco de dados ainda pode exibir gravações e consultas, mas em uma taxa mais lenta.

Recomendamos adicionar índices essenciais para o aplicativo de negócios antes de carregar os dados. Para todos os índices não críticos, adicione-os depois que os dados forem migrados.

Testar e medir a capacidade

A previsão da capacidade pode ser difícil. Teste sua estratégia de carregamento em massa antes de executar a carga final. Para um exemplo detalhado usando o particionamento e o monitoramento do desempenho, consulte Como maximizar a capacidade do carregamento de dados.

Práticas recomendadas para carregamento em massa periódico em um banco de dados atual

Se você estiver atualizando um banco de dados que contém dados, mas não tem índices secundários, as recomendações neste documento ainda serão válidas.

Caso tenha índices secundários, as instruções podem produzir um desempenho razoável. Ele depende de quantas divisões, em média, estão envolvidas nas transações. Se a capacidade cair muito, tente o seguinte:

  • Inclua um número menor de mutações em cada confirmação, o que pode aumentar a capacidade.
  • Se o upload for maior que o tamanho atual total da tabela sendo atualizada, exclua os índices secundários e adicione-os novamente depois de fazer o upload dos dados. Essa etapa geralmente não é necessária, mas pode melhorar a capacidade.