Partilhar via

Aumentar o desempenho do débito da Base de Dados SQL do Azure a partir do Azure Stream Analytics

  • Artigo

Este artigo aborda sugestões para obter um melhor desempenho de débito de escrita ao carregar dados para a Base de Dados SQL do Azure com o Azure Stream Analytics.

A saída do SQL no Azure Stream Analytics suporta a escrita em paralelo como uma opção. Esta opção permite topologias de tarefas totalmente paralelas , em que várias partições de saída estão a escrever na tabela de destino em paralelo. No entanto, a ativação desta opção no Azure Stream Analytics pode não ser suficiente para obter débitos mais elevados, uma vez que depende significativamente da configuração da base de dados e do esquema da tabela. A escolha de índices, chave de clustering, fator de preenchimento de índice e compressão tem um impacto no tempo para carregar tabelas. Para obter mais informações sobre como otimizar a base de dados para melhorar o desempenho de consultas e carga com base em referências internas, veja Base de Dados SQL orientações de desempenho. A ordenação de escritas não é garantida ao escrever em paralelo com Base de Dados SQL.

Seguem-se algumas configurações em cada serviço que podem ajudar a melhorar o débito geral da sua solução.

Azure Stream Analytics

  • Herdar a Criação de Partições – esta opção de configuração de saída do SQL permite herdar o esquema de criação de partições do passo ou entrada da consulta anterior. Com esta opção ativada, escrever numa tabela baseada em disco e ter uma topologia totalmente paralela para a sua tarefa, espera ver melhores débitos. Esta criação de partições já ocorre automaticamente para muitas outras saídas. O bloqueio de tabelas (TABLOCK) também está desativado para inserções em massa efetuadas com esta opção.

    Nota

    Quando existem mais de 8 partições de entrada, herdar o esquema de criação de partições de entrada pode não ser uma escolha adequada. Este limite superior foi observado numa tabela com uma única coluna de identidade e um índice agrupado. Neste caso, considere utilizar o INTO 8 na consulta para especificar explicitamente o número de escritores de saída. Com base no esquema e na escolha dos índices, as suas observações podem variar.

  • Tamanho do Batch – a configuração de saída do SQL permite-lhe especificar o tamanho máximo do lote numa saída sqL do Azure Stream Analytics com base na natureza da tabela/carga de trabalho de destino. O tamanho do lote é o número máximo de registos enviados com cada transação de inserção em massa. Nos índices columnstore agrupados, os tamanhos de lote de cerca de 100 mil permitem uma maior paralelização, registo mínimo e otimizações de bloqueio. Nas tabelas baseadas em disco, 10 mil (predefinição) ou inferior podem ser ideais para a sua solução, uma vez que tamanhos de lote mais elevados podem acionar o escalamento de bloqueios durante as inserções em massa.

  • Otimização da Mensagem de Entrada – se tiver otimizado a utilização da criação de partições herdar e o tamanho do lote, aumentar o número de eventos de entrada por mensagem por partição ajuda a aumentar ainda mais o débito de escrita. A otimização de mensagens de entrada permite que os tamanhos dos lotes no Azure Stream Analytics estejam à medida do Tamanho do Batch especificado, melhorando assim o débito. Isto pode ser conseguido através da compressão ou do aumento do tamanho das mensagens de entrada no EventHub ou no Blob.

SQL Azure

  • Índices e Tabelas Particionadas – utilizar uma tabela SQL particionada e índices particionados na tabela com a mesma coluna que a chave de partição (por exemplo, PartitionId) pode reduzir significativamente as contenção entre partições durante as escritas. Para uma tabela particionada, terá de criar uma função de partição e um esquema de partição no grupo de ficheiros PRIMARY. Isto também aumentará a disponibilidade dos dados existentes enquanto estão a ser carregados novos dados. O limite de E/S de registo pode ser atingido com base no número de partições, o que pode ser aumentado ao atualizar o SKU.

  • Evitar violações de chaves exclusivas – se receber várias mensagens de aviso de violação de chaves no Registo de Atividades do Azure Stream Analytics, certifique-se de que a sua tarefa não é afetada por violações de restrição exclusivas que são susceptíveis de ocorrer durante os casos de recuperação. Isto pode ser evitado ao definir a opção IGNORE_DUP_KEY nos seus índices.

tabelas de Azure Data Factory e In-Memory

  • Tabela Dentro da Memória como tabela temporária – as tabelas Dentro da Memória permitem cargas de dados de alta velocidade, mas os dados têm de caber na memória. As referências mostram que o carregamento em massa de uma tabela dentro da memória para uma tabela baseada em disco é cerca de 10 vezes mais rápido do que a inserção direta em massa através de um único escritor na tabela baseada em disco com uma coluna de identidade e um índice em cluster. Para tirar partido deste desempenho de inserção em massa, configure uma tarefa de cópia com Azure Data Factory que copia dados da tabela dentro da memória para a tabela baseada em disco.

Evitar Falhas de Desempenho

A inserção em massa de dados é muito mais rápida do que carregar dados com inserções individuais porque a sobrecarga repetida de transferir os dados, analisar a instrução inserir, executar a instrução e emitir um registo de transação é evitada. Em vez disso, é utilizado um caminho mais eficiente no motor de armazenamento para transmitir os dados em fluxo. O custo de configuração deste caminho é, no entanto, muito superior a uma única instrução de inserção numa tabela baseada em disco. O ponto de break-even é normalmente cerca de 100 linhas, para além do qual o carregamento em massa é quase sempre mais eficiente.

Se a taxa de eventos recebidos for baixa, pode criar facilmente tamanhos de lote inferiores a 100 linhas, o que torna a inserção em massa ineficiente e utiliza demasiado espaço em disco. Para contornar esta limitação, pode realizar uma destas ações:

  • Crie um acionador EM VEZ de DE para utilizar a inserção simples para cada linha.
  • Utilize uma tabela temporária In-Memory, conforme descrito na secção anterior.

Outro cenário deste tipo ocorre ao escrever num índice columnstore (NCCI) não agrupado, onde inserções em massa mais pequenas podem criar demasiados segmentos, o que pode falhar o índice. Neste caso, a recomendação consiste em utilizar um índice Columnstore em Cluster.

Resumo

Em resumo, com a funcionalidade de saída particionada no Azure Stream Analytics para a saída do SQL, a paralelização alinhada da tarefa com uma tabela particionada no SQL Azure deverá proporcionar-lhe melhorias significativas de débito. Tirar partido de Azure Data Factory para orquestrar o movimento de dados de uma tabela In-Memory em tabelas baseadas em disco pode dar ordem de ganhos de débito de magnitude. Se for viável, a melhoria da densidade das mensagens também pode ser um fator importante para melhorar o débito geral.

Passos seguintes