Partilhar via

Referência da DTU

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Uma unidade de transação de banco de dados (DTU) é uma unidade de medida que representa uma medida combinada de CPU, memória, leituras e gravações. As características físicas (CPU, memória, E/S) associadas a cada medida DTU são calibradas usando um benchmark que simula a carga de trabalho do banco de dados do mundo real. Este artigo resume o benchmark da DTU e compartilha informações sobre o esquema, os tipos de transação usados, a combinação de carga de trabalho, os usuários e o ritmo, as regras de dimensionamento e as métricas associadas ao benchmark.

Para obter informações gerais sobre o modelo de compra baseado em DTU, consulte a visão geral do modelo de compra baseado em DTU.

Resumo do índice de referência

O benchmark DTU mede o desempenho de uma combinação de operações básicas de banco de dados que ocorrem com mais frequência em cargas de trabalho OLTP (processamento de transações online). Embora o benchmark seja projetado com a computação em nuvem em mente, o esquema do banco de dados, o preenchimento de dados e as transações foram projetados para serem amplamente representativos dos elementos básicos mais comumente usados em cargas de trabalho OLTP.

Correlacionando os resultados de benchmark com o desempenho do banco de dados do mundo real

É importante entender que todos os benchmarks são representativos e meramente indicativos. As taxas de transação alcançadas com a aplicação de referência não serão as mesmas que poderiam ser alcançadas com outras aplicações. O índice de referência compreende uma coleção de diferentes tipos de transações executadas em relação a um esquema que contém uma gama de tabelas e tipos de dados. Embora o benchmark exerça as mesmas operações básicas que são comuns a todas as cargas de trabalho OLTP, ele não representa nenhuma classe específica de banco de dados ou aplicativo. O objetivo do benchmark é fornecer um guia razoável para o desempenho relativo de um banco de dados que pode ser esperado ao aumentar ou diminuir a escala entre tamanhos de computação.

Na realidade, os bancos de dados são de tamanhos e complexidades diferentes, encontram diferentes combinações de cargas de trabalho e responderão de maneiras diferentes. Por exemplo, um aplicativo com uso intensivo de E/S pode atingir os limites de E/S mais cedo ou um aplicativo com uso intensivo de CPU pode atingir os limites de CPU mais cedo. Não há garantia de que qualquer banco de dados específico será dimensionado da mesma forma que o benchmark sob carga crescente.

O parâmetro de referência e a sua metodologia são descritos mais pormenorizadamente neste artigo.

Esquema

O esquema foi projetado para ter variedade e complexidade suficientes para suportar uma ampla gama de operações. O benchmark é executado em relação a um banco de dados composto por seis tabelas. As tabelas se dividem em três categorias: tamanho fixo, dimensionamento e crescimento. Existem duas tabelas de tamanho fixo; três tabelas de escala; e uma mesa de cultivo. As tabelas de tamanho fixo têm um número constante de linhas. As tabelas de dimensionamento têm uma cardinalidade que é proporcional ao desempenho do banco de dados, mas não muda durante o benchmark. A tabela crescente é dimensionada como uma tabela de dimensionamento na carga inicial, mas a cardinalidade muda durante a execução do benchmark à medida que as linhas são inseridas e excluídas.

O esquema inclui uma combinação de tipos de dados, incluindo inteiro, numérico, caractere e data/hora. O esquema inclui chaves primárias e secundárias, mas não quaisquer chaves estrangeiras - ou seja, não há restrições de integridade referencial entre tabelas.

Um programa de geração de dados gera os dados para o banco de dados inicial. Dados inteiros e numéricos são gerados com várias estratégias. Em alguns casos, os valores são distribuídos aleatoriamente ao longo de um intervalo. Em outros casos, um conjunto de valores é permutado aleatoriamente para garantir que uma distribuição específica seja mantida. Os campos de texto são gerados a partir de uma lista ponderada de palavras para produzir dados realistas.

O banco de dados é dimensionado com base em um fator de escala. O fator de escala (abreviado como SF) determina a cardinalidade das tabelas de escala e crescimento. Conforme descrito abaixo na seção Usuários e Preparação, o tamanho do banco de dados, o número de usuários e o desempenho máximo são dimensionados proporcionalmente uns aos outros.

Transações

A carga de trabalho consiste em nove tipos de transação, conforme mostrado na tabela abaixo. Cada transação é projetada para destacar um conjunto particular de características do sistema no mecanismo de banco de dados e no hardware do sistema, com alto contraste das outras transações. Esta abordagem facilita a avaliação do impacto dos diferentes componentes no desempenho global. Por exemplo, a transação "Read Heavy" produz um número significativo de operações de leitura do disco.

Tipo de Transação Description
Leia Lite SELECIONAR; na memória; somente leitura
Ler Médio SELECIONAR; principalmente na memória; somente leitura
Ler Pesado SELECIONAR; a maioria não está na memória; somente leitura
Atualizar Lite ATUALIZAÇÃO; na memória; leitura-escrita
Atualização pesada ATUALIZAÇÃO; a maioria não está na memória; leitura-escrita
Inserir Lite INSERIR; na memória; leitura-escrita
Inserir pesado INSERIR; a maioria não está na memória; leitura-escrita
Delete SUPRIMIR; mistura de in-memory e não in-memory; leitura-escrita
CPU pesada SELECIONAR; na memória; carga relativamente pesada da CPU; somente leitura

Combinação de carga de trabalho

As transações são selecionadas aleatoriamente a partir de uma distribuição ponderada com a seguinte combinação geral. A mistura geral tem uma relação leitura/gravação de aproximadamente 2:1.

Tipo de Transação % da mistura
Leia Lite 35
Ler Médio 20
Ler Pesado 5
Atualizar Lite 20
Atualização pesada 3
Inserir Lite 3
Inserir pesado 2
Delete 2
CPU pesada 10

Usuários e ritmo

A carga de trabalho de referência é orientada a partir de uma ferramenta que envia transações em um conjunto de conexões para simular o comportamento de vários usuários simultâneos. Embora todas as conexões e transações sejam geradas por máquinas, para simplificar, nos referimos a essas conexões como usuários. Embora cada usuário opere independentemente de todos os outros usuários, todos os usuários executam o mesmo ciclo de etapas mostrado abaixo:

  1. Estabeleça uma conexão de banco de dados.
  2. Repita até sinalizar para sair:
    • Selecione uma transação aleatoriamente (a partir de uma distribuição ponderada).
    • Execute a transação selecionada e meça o tempo de resposta.
    • Aguarde um atraso no ritmo.
  3. Feche a conexão do banco de dados.
  4. Sair.

O atraso de estimulação (no passo 2c) é selecionado aleatoriamente, mas com uma distribuição que tem uma média de 1,0 segundo. Assim, cada usuário pode, em média, gerar no máximo uma transação por segundo.

Regras de dimensionamento

O número de usuários é determinado pelo tamanho do banco de dados (em unidades de fator de escala). Há um usuário para cada cinco unidades de fator de escala. Devido ao atraso de ritmo, um usuário pode gerar no máximo uma transação por segundo, em média.

Por exemplo, um banco de dados de fator de escala de 500 (SF=500) terá 100 usuários e pode atingir uma taxa máxima de 100 TPS. Para gerar uma taxa de TPS mais alta requer mais usuários e um banco de dados maior.

Duração da medição

Um ensaio de referência válido requer uma duração de medição em condições estacionárias de, pelo menos, uma hora.

Métricas

As principais métricas no benchmark são taxa de transferência e tempo de resposta.

  • A taxa de transferência é a medida de desempenho essencial no benchmark. A taxa de transferência é relatada em transações por unidade de tempo, contando todos os tipos de transação.
  • O tempo de resposta é uma medida de previsibilidade de desempenho. A restrição de tempo de resposta varia de acordo com a classe de serviço, com classes mais altas de serviço tendo um requisito de tempo de resposta mais rigoroso, como mostrado abaixo.
Classe de Serviço Medida de taxa de transferência Requisito de tempo de resposta
Premium Transações por segundo percentil 95 a 0,5 segundos
Standard Transações por minuto percentil 90 a 1,0 segundos
Básica Transações por hora percentil 80 a 2,0 segundos

Nota

As métricas de tempo de resposta são específicas para o Benchmark da DTU. Os tempos de resposta para outras cargas de trabalho dependem da carga de trabalho e serão diferentes.

Próximos passos

Saiba mais sobre modelos de compra e conceitos relacionados nos seguintes artigos: