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:
- 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.
- Importar dados no formato CSV.
Embora seja possível inserir linhas usando a CLI do Google Cloud, 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, use o particionamento ao máximo para distribuir a gravação dos dados nas tarefas do worker.
O Spanner usa a divisão baseada em carga para distribuir uniformemente os o carregamento de dados nos recursos de computação da instância. Após alguns minutos de alta carga, o Spanner lança 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 automaticamente as tabelas em intervalos menores. O 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 em sua 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 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.
Se você decidir não usar partições
Gravar linhas aleatórias dentro de uma confirmação pode ser mais lento do que gravar um conjunto contíguo de linhas em uma confirmação e, provavelmente, tocar em dados em diferentes partições diferentes. A latência de confirmação e a sobrecarga são maiores quando mais divisões estão sendo gravados em um commit, devido à maior coordenação entre os servidores. Várias divisões provavelmente estão 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 anteriormente, a capacidade de gravação é reduzida quando mais divisões estão envolvidas.
Carregar 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, há mais coordenação servidores são necessários, aumentando a latência e a sobrecarga de confirmação.
Provavelmente, várias partições estão envolvidas porque cada linha aleatória pode pertencer para uma partição diferente. Na pior das hipóteses, cada gravação envolve todas as partições da instância do Spanner. Conforme mencionado anteriormente, a capacidade de gravação é diminuída 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 resistência. Para transações somente gravação, o Spanner repete automaticamente a transação. Nesses casos, a resposta aparece como latência alta. Durante cargas pesadas, ele pode levar até um minuto. Durante cargas muito pesadas, o pushback pode durar vários minutos. Para evitar resistência, é necessário limitar as solicitações de gravação para manter o uso da CPU dentro 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 a gravação é grande ou pequeno. Para maximizar a capacidade, maximize 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 sua índices ao mesmo tempo, envie as instruções DDL para a nova tabela e o novos índices em uma única solicitação ao 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é todas as alterações no esquema foram concluídas. O banco de dados ainda pode exibir gravações e consultas, mas em uma velocidade mais lenta.
Recomendamos adicionar índices essenciais ao 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.