Nesta página, apresentamos diretrizes para o carregamento eficiente em massa de grandes quantidades de dados no Spanner.
Você tem várias opções para carregar dados em massa no Spanner:
- Inserir linhas usando a linguagem de manipulação de dados (DML).
- Inserir linhas usando mutações.
- Importar dados usando o conector do Dataflow.
- Importar um banco de dados usando arquivos Avro.
- Importe dados no formato CSV.
Também é possível inserir linhas usando a Google Cloud CLI, mas não recomendamos o uso da CLI gcloud para carregamento em massa.
Diretrizes de desempenho para carregamento em massa
Para alcançar 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 carga alta, o Spanner introduz limites de divisão 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 dinamicamente 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 você carrega dados, 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.
Se você decidir não usar partições
Gravar linhas aleatórias em uma confirmação pode ser mais lento do que gravar um conjunto contíguo de linhas e, provavelmente, tocar dados em diferentes partições. A latência e a sobrecarga de confirmação são maiores quando mais divisões estão sendo gravadas em um commit, devido ao aumento da coordenação entre os servidores. É provável que várias divisões estejam envolvidas, porque cada linha aleatória pode pertencer a uma divisão diferente. Na pior das hipóteses, cada gravação envolve todas as divisões na instância do Spanner. Conforme mencionado acima, a capacidade de gravação é reduzida quando mais divisões estão envolvidas.
Carregar em massa sem particionamento
Gravar um conjunto contíguo de linhas em uma confirmação pode ser mais rápido do que escrever linhas aleatórias. É provável que as linhas aleatórias também incluam dados de partições diferentes.
Quando mais partições são gravadas em um commit, é necessário mais coordenação entre os servidores, aumentando a latência e a sobrecarga de confirmação.
É provável que várias partições estejam 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 acima, a capacidade de gravação diminui quando mais partições estão envolvidas.
Evitar sobrecarga
É possível enviar mais solicitações de gravação do que o Spanner consegue processar. O Spanner processa a sobrecarga cancelando transações, o que é chamado de pushback. Para transações somente gravação, o Spanner tenta realizar a transação automaticamente de novo. Nesses casos, o pushback aparece como alta latência. Durante cargas pesadas, ele pode levar até um minuto. Durante cargas muito pesadas, ele pode levar vários minutos. Para evitá-lo, 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 permaneça 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, esteja ciente de que 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 e correm o risco de exceder os limites do Spanner em tamanho de confirmação e 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 atender gravações e consultas, mas em uma taxa mais lenta.
Recomendamos adicionar índices essenciais para o aplicativo comercial antes de carregar os dados. Para todos os índices não críticos, adicione-os após a migração dos dados.
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 atual que contém dados, mas não tem índices secundários, as recomendações neste tópico ainda se aplicam.
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.