Planejar implantações de Banco de Dados do Azure para PostgreSQL para desempenho operacional

A computação em nuvem remodelou drasticamente o cenário de hospedagem do banco de dados. Ele fornece às equipes acesso à escalabilidade, resiliência, alcance global e funcionalidades que antes eram inalcançáveis. Em vez de incorrer em custos consideráveis e sobrecarga planejando a maior carga de trabalho possível (e carregando esse custo desde o primeiro dia), as equipes agora podem otimizar em torno da escala precisa de que precisam, quando precisam e ajustar à medida que suas demandas mudam.

Introduction

A flexibilidade para escolher o equilíbrio apropriado de recursos é especialmente valiosa para implantações de banco de dados PostgreSQL. As cargas de trabalho do banco de dados PostgreSQL podem começar pequenas, crescer rapidamente, ter picos sazonais, mudar de intensiva em leitura para intensiva em gravação ou evoluir de cargas de trabalho transacionais para sistemas híbridos operacionais e analíticos em tempo real. Banco de Dados do Azure para PostgreSQL garante que suas soluções atinjam seus destinos oferecendo uma ampla gama de opções entre computação, armazenamento, disponibilidade, replicação, segurança, backup e gerenciamento operacional.

Mas com todo esse poder vem a responsabilidade, especialmente ao planejar suas implantações. Para obter o melhor desempenho possível, suas decisões de implantação devem corresponder aos requisitos gerais da carga de trabalho.

Uma implantação de Banco de Dados do Azure para PostgreSQL bem-sucedida não é apenas uma questão de escolher "a maioria dos núcleos e memória de que precisamos". Em vez disso, o desempenho operacional máximo vem da compreensão dos comportamentos do aplicativo, dos comportamentos do cliente, da computação, do armazenamento e das características de crescimento do banco de dados e de como todos eles se cruzam e interagem.

A melhor arquitetura é aquela em que essas peças são alinhadas intencionalmente.

O planejamento de desempenho de nuvem é uma responsabilidade compartilhada

Um dos principais benefícios da mudança para uma plataforma de nuvem confiável é o modelo de responsabilidade compartilhada. Microsoft fornece infraestrutura global, serviços gerenciados, inovação de hardware, confiabilidade, segurança e engenharia operacional. Suas equipes trazem a experiência específica do contexto do aplicativo: comercialmente crítico, comportamento de carga de trabalho, design de modelo de dados, perfil de tráfego de rede, expectativas de crescimento, objetivos de recuperação e requisitos de experiência do usuário final.

Os resultados mais fortes surgem quando essas duas forças são unificadas.

Azure fornece infraestrutura de Postgres altamente escalonável, mas sua equipe deve trazer insights para essas áreas:

Quantos usuários simultâneos são esperados durante os períodos normais e de pico?
As operações mais importantes são focadas em leitura, focadas em escrita ou mistas?
A demanda aumenta durante o final do mês, trimestre, feriados, lançamentos ou janelas de relatórios?
Qual é a rapidez com que o conjunto de dados está crescendo?
Quais operações são sensíveis à latência?
Quais consultas ou trabalhos podem tolerar tempos de execução mais longos?
A carga de trabalho é principalmente OLTP, OLAP ou híbrida?
Os clientes estão localizados perto da região do banco de dados, distribuídos globalmente ou concentrados em uma geografia?

Capture esses detalhes antes da implantação, não após um incidente de produção. As implantações de nuvem facilitam o dimensionamento, mas os designs de alto desempenho e mais econômicos ainda começam com a coleta de requisitos sólidos e o planejamento adequado. Na maioria dos casos, essas perguntas podem ser destiladas até as relações entre conexões simultâneas, IOPS máxima e taxa de transferência necessária.

O desempenho tem várias camadas

O desempenho do banco de dados raramente é determinado por uma única configuração. As experiências de implantação bem-sucedidas dependem de várias camadas trabalhando juntas:

Desempenho da camada de aplicativo.
Essa camada inclui código da aplicação, padrões de consulta, cobertura de índice, uso de gatilhos, particionamento de dados, tratamento de conexão, caching, lógica de repetição, pooling, comportamento ORM, projeto de transação e comportamento de processamento em segundo plano.
Desempenho da camada de rede e cliente.
Essa camada inclui onde os clientes estão localizados, como eles se conectam, se as solicitações atravessam regiões e zonas de disponibilidade, a latência de rede, a sobrecarga de TLS, a mudança excessiva de conexões e se o aplicativo utiliza o pooling de conexões com eficiência.
Desempenho da plataforma de banco de dados.
Essa camada inclui configuração de implantação do Postgres, tamanho da computação, memória, CPU, tipo de armazenamento, tamanho do armazenamento, IOPS de armazenamento, taxa de transferência de armazenamento, alta disponibilidade, réplicas e operações de manutenção.

Este artigo se concentra principalmente na terceira camada: planejar a implantação do banco de dados Azure Postgres para que as opções de computação e armazenamento ofereçam suporte ao perfil de desempenho necessário.

Banco de Dados do Azure para PostgreSQL oferece flexibilidade, mas o planejamento é essencial

Servidor Flexível do Banco de Dados do Azure para PostgreSQL fornece uma variedade de opções de implantação, incluindo:

Área de implantação	Opções disponíveis
Computação	Camadas de computação, gerações de VM (máquina virtual), configurações de Uso Geral e configurações otimizadas para memória.
Armazenamento	Azure SSD Premium v1, SSD Premium v2, dimensionamento de armazenamento, configuração de IOPS e configuração de taxa de transferência.
Disponibilidade	Alta disponibilidade, backup e restauração, e backups geograficamente redundantes em configurações com suporte.
Replication	Réplicas de leitura e réplicas geográficas.
Segurança	Chaves gerenciadas pelo cliente e integração de segurança corporativa.

Essa flexibilidade é poderosa porque cargas de trabalho diferentes exigem diferentes funcionalidades. Um sistema transacional intensivo em gravação não precisa do mesmo perfil que um sistema intensivo em geração de relatórios. Um aplicativo SaaS global não precisa do mesmo design de um aplicativo regional interno. Um banco de dados que cresce 5% por ano não precisa do mesmo plano de armazenamento que um que cresce 200% mês a mês.

A meta de planejamento é identificar as necessidades do perfil de desempenho da carga de trabalho e implementar as opções adequadas em opções de computação e armazenamento para fornecer suas soluções de ponta a ponta com êxito.

Comece com o perfil de carga de trabalho

Antes de escolher computação ou armazenamento, defina a carga de trabalho. Dimensões de planejamento úteis incluem:

Área de planejamento	Perguntas a serem respondidas
Geografia	Onde estão localizados usuários, aplicativos, réplicas e integrações?
Concurrency	Quantas conexões simultâneas e consultas ativas são esperadas?
Tamanho dos dados	Qual é o tamanho atual do banco de dados e qual é a taxa de crescimento esperada?
Taxa de alteração	A rapidez com que os dados crescem mês a mês? Quanto WAL (Log de Gravação Antecipada) é gerado?
Tipo de carga de trabalho	O sistema é OLTP, OLAP, focado em relatórios, focado em processamento em lote ou híbrido?
Combinação de leitura/gravação	Qual porcentagem de operações são leituras e gravações?
Comportamento de pico	Há ciclos de negócios previsíveis, picos sazonais ou janelas em lotes?
Sensibilidade de latência	Quais transações são voltadas para o usuário e críticas em termos de latência?
Necessidades de taxa de transferência	Há escaneamentos de dados, exportações, importações ou processos de ETL (extração, transformação e carregamento) em grande escala?
Dimensionamento de expectativas	A carga de trabalho precisará de intermitências temporárias ou maior desempenho sustentado?

O objetivo não é prever o futuro perfeitamente. O objetivo é evitar o design às cegas.

Entender os três principais conceitos de desempenho de armazenamento

Azure planejamento de desempenho de armazenamento geralmente se resume a três conceitos relacionados, mas distintos: IOPS, taxa de transferência e latência. Esses fatores são fundamentais para o planejamento do desempenho do aplicativo.

IOPS

IOPS significa operações de entrada/saída por segundo. Ele mede quantas operações de leitura ou gravação o banco de dados pode enviar ao armazenamento a cada segundo.

O IOPS é especialmente importante para cargas de trabalho OLTP. Esses sistemas geralmente executam muitas leituras e gravações pequenas e aleatórias, como inserções, atualizações, pesquisas de índice, leituras de ponto e transações curtas. Uma carga de trabalho transacional com milhares de usuários simultâneos pode precisar de IOPS alta mesmo que cada operação individual seja pequena.

Cenários comuns sensíveis ao IOPS incluem:

Processamento de pedidos de alto volume
Atualizações de perfil do usuário
Sistemas de inventário
Ingestão de eventos
Sistemas de pagamento ou cobrança
Aplicativos SaaS altamente simultâneos

Produtividade

A taxa de transferência, às vezes chamada de largura de banda, mede a quantidade de dados que podem ser lidos ou gravados no armazenamento ao longo do tempo. Ele é expresso em MB/s.

A taxa de transferência é importante quando as operações movem grandes quantidades de dados. Consultas analíticas, backups, restaurações, trabalhos em lotes, builds de índice, verificações de tabela e fluxos de trabalho ETL podem precisar de alta taxa de transferência, mesmo que não exijam o IOPS mais alto.

Cenários comuns que são sensíveis à taxa de transferência incluem:

Relatando consultas em tabelas grandes
Importações ou exportações em massa
Verificações no estilo data warehouse
Operações de backup e restauração
Operações de criação ou reconstrução de índices grandes
Processamento em lotes

Latency

Latência é o tempo necessário para que uma única solicitação de E/S seja concluída. A baixa latência é essencial para operações de banco de dados voltadas para o usuário, especialmente quando muitas pequenas operações são encadeadas em uma transação.

Um sistema pode ter alta IOPS teórica, mas ainda se sentir lento se a latência for alta. Para cargas de trabalho do Postgres, a latência de armazenamento pode afetar diretamente os tempos de resposta da consulta, o comportamento de confirmação da transação, o comportamento do ponto de verificação e a capacidade de resposta geral do aplicativo.

Note

Os discos Premium SSD v1 são projetados para oferecer latências de milissegundos em dígito único na maioria das operações de E/S e, notadamente, o cache de disco pode diminuir ainda mais a latência de leitura em configurações de disco abaixo de 4 TB. O SSD Premium v2 e o Ultra Disk oferecem latência de submilissegundo.

IOPS, taxa de transferência e latência devem ser considerados juntos

O IOPS e a taxa de transferência estão conectados. Uma carga de trabalho emitindo várias pequenas operações de 8 KiB pode gerar alta IOPS sem uma alta taxa de transferência. Uma carga de trabalho emitindo grandes operações de vários MB pode gerar alta taxa de transferência com IOPS inferior.

Uma maneira simples de pensar sobre isso:

IOPS x Tamanho de E/S = Taxa de transferência

Para o Postgres, a implicação prática é que o planejamento de armazenamento de carga de trabalho deve ser baseado no comportamento de carga de trabalho observado ou estimado, não apenas no tamanho do banco de dados. Por exemplo:

Um sistema OLTP de alta simultaneidade pode precisar de mais IOPS e latência mais baixa.
Um sistema intenso em relatórios pode precisar de mais capacidade de processamento.
Um sistema híbrido pode precisar de ambos, especialmente durante os ciclos de pico.
Um sistema OLTP de alta simultaneidade pode precisar de mais IOPS e latência mais baixa.
Um sistema com carga intensa de relatórios talvez precise de mais taxa de transferência.
Um sistema híbrido pode precisar de ambos, especialmente durante os ciclos de pico.

Suas opções de implantação afetam diretamente o desempenho do armazenamento

Um erro comum é configurar o armazenamento para uma meta de desempenho sem considerar se a SKU de computação selecionada pode suportar os mesmos níveis de desempenho.

O desempenho de armazenamento do Azure tem várias considerações. Os detalhes incluem:

O conjunto de recursos de computação (limite máximo de IOPS e taxa de transferência de computação).
A geração de armazenamento (SSD v1, SSD v2, Ultra Disk).
O tamanho do disco de armazenamento (discos SSD v1 com menos de 4.096 GB incluem cache de host, o que permite intermitências de IOPS acima das linhas de base padrão).
A capacidade de IOPS de armazenamento.
A capacidade de transferência de dados do armazenamento.

Em termos práticos: seu teto de desempenho efetivo é seu menor limite relevante na cadeia.

Se a configuração de armazenamento puder fornecer 80.000 IOPS, mas a SKU de computação só puder gerar 20.000 IOPS, a implantação não fornecerá 80.000 IOPS. Por outro lado, se a geração da VM suporta alta IOPS, mas a camada de armazenamento selecionada tem um limite inferior, a camada de armazenamento passa a ser o limite.

O planejamento de computação e armazenamento deve ocorrer em conjunto.

SSD Premium v1: desempenho de linha de base forte com comportamento importante de cache

O SSD Premium v1 é uma opção comum para cargas de trabalho de produção Azure Postgres que precisam de desempenho previsível e provisionado. Armazenamento SSD do Azure Postgres v1 dá suporte a até 32 TB de espaço, 20.000 IOPS e 900 MB/s de taxa de transferência.

O SSD premium v1 funciona bem para cargas de trabalho que se beneficiam do cache de host. Azure Postgres dá suporte ao cache de host para tamanhos de disco SSD v1 sem mais de 4.096 GB. Qualquer disco provisionado com até 4.095 GB pode se beneficiar do cache do host. Depois que o armazenamento é provisionado a 4.096 GB ou superior, não há suporte para cache de host. Esse limite importa. Para implantações de Premium SSD v1 abaixo de 4 TB, o cache pode melhorar o desempenho de leitura e reduzir a latência de leitura. Esse cache proporciona uma excelente relação custo-benefício para eficiência de desempenho em cargas de trabalho com leitura pesada ou mistas que se enquadram abaixo do limite de armazenamento em cache.

Por que o limite de 4 TB importa

Quando uma implantação do SSD Premium v1 cresce além do intervalo com suporte para cache, o perfil de desempenho pode mudar:

As leituras não se beneficiam mais do cache de host.
Mais operações de leitura vêm diretamente do disco subjacente.
As leituras contam contra os limites de IOPS de disco e de taxa de transferência.
Cargas de trabalho de leitura sensíveis à latência podem apresentar um comportamento diferente.
Uma configuração anteriormente eficiente pode precisar de mais IOPS provisionado, mais taxa de transferência, dimensionamento de computação, ajuste de consulta ou uma opção de armazenamento diferente.

Ultrapassar 4 TB não é um problema, mas você deve planejar para isso.

Se você espera que um banco de dados cresça além de 4 TB, considere o estado futuro durante o design da arquitetura. Um design que tem um bom desempenho em 2 TB com cache pode precisar de um plano de desempenho diferente em 5 TB sem cache.

A intermitência ajuda com picos, mas não substitui a capacidade sustentada

Alocações de armazenamento do Azure Postgres Premium SSD v1 abaixo de 4 TB suportam picos de cache de host, o que pode ajudar em cenários como:

Atividade de inicialização
Trabalhos em lotes curtos
Picos de tráfego
Processamento de fim de mês
Aumentos temporários de carga de trabalho

Embora o bursting seja útil, use-o com cuidado. O bursting pode absorver picos temporários, mas não deve ser a base para a demanda sustentada de carga de trabalho. Se a carga de trabalho for executada com frequência acima da linha de base, é melhor provisionar uma camada de desempenho mais alta, ajustar as configurações de desempenho de armazenamento, dimensionar a computação ou reprojetar o padrão de carga de trabalho.

Uma boa pergunta de planejamento é: este é um pico temporário, ou este é o novo normal?

Picos temporários podem ser bons candidatos para bursting. Gerenciar a demanda sustentada com planejamento de capacidade deliberado.

O SSD Premium v2 separa a capacidade, o IOPS e a taxa de transferência

O SSD Premium v2 altera o modelo de planejamento desassociando o tamanho do disco, o IOPS e a taxa de transferência. Banco de Dados do Azure para PostgreSQL servidor flexível com suporte ao SSD Premium v2:

Capacidade de 32 GB a 64 TB.
Até 80.000 IOPS.
Até 1.200 MB/s de taxa de transferência.
Ajustes de capacidade granular em incrementos de 1 GB cada.
Configuração flexível de IOPS e taxa de transferência.
Latência menor do que o SSD Premium v1.
Nenhum cache de host.

Essa alteração é uma mudança importante. Com o SSD Premium v1, o desempenho é mais firmemente acoplado ao tamanho do disco. Com o SSD Premium v2, você pode configurar o desempenho mais diretamente em relação à necessidade de carga de trabalho.

Por exemplo, um banco de dados de transação pesada pode precisar de IOPS alto sem precisar de uma grande quantidade de armazenamento. Azure Postgres fornece IOPS de linha de base e taxa de transferência sem custo adicional, com IOPS adicional e taxa de transferência disponíveis para encargos adicionais. Ofertas do SSD premium v2:

Discos de até 399 GB recebem uma linha de base de 3.000 IOPS e 125 MB/s.
Os discos de 400 GB ou maiores recebem uma linha de base de 12.000 IOPS e 500 MB/s.
Os discos podem alcançar até 80.000 IOPS quando dimensionados para pelo menos 160 GB de espaço disponível.
A taxa de transferência pode aumentar até 1.200 MB/s.

O SSD Premium v2 geralmente é atraente quando você precisa de um controle mais preciso sobre o custo e o desempenho. Em vez de dimensionar a capacidade de armazenamento apenas para desbloquear o desempenho, você pode provisionar o desempenho mais intencionalmente.

Disco Ultra (versão prévia): a classe de alto desempenho de disco do Azure

O Disco Ultra é a opção de disco de maior desempenho. Azure Ultra Disk oferece níveis de desempenho até:

400.000 IOPS
Desempenho de 10.000 MB/s
Capacidade de 64 TB
Metas de design de latência de submilissegundos
Capacidade, IOPS e taxa de transferência configuráveis de forma independente

O armazenamento de Disco Ultra foi projetado para alimentar cargas de trabalho com uso intensivo de E/S para bancos de dados de nível superior, SAP HANA e sistemas transacionais pesados. Essa nova oferta de armazenamento fornece um desempenho de primeira linha para suas cargas de trabalho críticas. No entanto, sua equipe deve considerar alguns dos principais recursos de implantação, restrições de disponibilidade regionais e opções de configuração ao planejar uma implantação:

Não há suporte para o crescimento automático de armazenamento para servidores usando o Ultra Disk
Não há suporte para criptografia de dados com chaves gerenciadas pelo cliente para servidores com Ultra Disk
Os Discos Ultra não dão suporte ao cache de disco

É importante entender os recursos do Ultra Disk como parte do cenário de desempenho de armazenamento Azure mais amplo. No entanto, você deve validar a disponibilidade do serviço e o suporte para sua carga de trabalho específica Azure Postgres. Verifique com seu representante Microsoft se a Visualização de Disco Ultra está disponível para sua implantação do Postgres Azure.

A conclusão prática: o Disco Ultra representa o alto nível de desempenho de armazenamento do Azure, contudo, o design completo do Postgres deve incluir combinações compatíveis para o SKU de computação selecionado, a região e a versão.

A geração de VM importa: os tetos de armazenamento de computação V5 e V6 são diferentes

A geração de computação pode afetar materialmente o desempenho do armazenamento. Ao explorar o mais alto nível de desempenho de armazenamento do Azure, evite o mal-entendido de que "alta capacidade de computação" significa automaticamente "capacidade máxima de armazenamento". É necessário validar a SKU de computação selecionada em relação à camada de armazenamento desejada. Vamos ilustrar este ponto considerando duas gerações de computação, Ddsv5 e Ddsv6, de tamanho semelhante:

A série Ddsv5 dá suporte a Armazenamento Premium (com cache), SSD Premium v2 e Ultra Disk no nível da família VM. No entanto, os limites de armazenamento remoto agregado da VM ainda definem o teto para o que essa VM pode dirigir. Ddsv5-series fornece desempenho de armazenamento que varia até 80.000 IOPS e 2.600 MB/s.

A Ddsv6série fornece um envelope de armazenamento mais alto, variando até 400.000 IOPS e 12.000 MB/s. A computação da série V6 também oferece maior escalabilidade do que as gerações anteriores, com até 192 vCPU e memória de 768 GiB.

Essa alteração geracional é importante para o design do Postgres de alto desempenho. Se sua arquitetura de destino exigir alto desempenho de armazenamento, escolher uma geração de computação com um teto de armazenamento de agregação mais baixo poderá impedir que a implantação use a funcionalidade de armazenamento completo.

Exemplo: por que o alinhamento de ponta a ponta importa

Considere uma carga de trabalho postgreSQL com uma meta de armazenamento aspiracional de 400.000 IOPS.

Na camada de disco, o Azure Ultra Disk dá suporte a até 400.000 IOPS por disco. O SSD Premium v2 dá suporte a até 80.000 IOPS por disco e designs de agregação mais altos podem exigir vários discos ou abstração no nível da plataforma, dependendo do suporte ao serviço.

Mas a capacidade de armazenamento por si só não é suficiente.

Uma configuração da série V5 pode ter um limite de armazenamento inferior ao alvo. Como mencionado anteriormente, os SKUs da série V5 dão suporte a até 260.000 IOPS para taxa de transferência de disco remoto do SSD Premium. Nesse caso, escolher a camada de computação da série V5 para esse destino torna-se o fator limitante antes que um destino de 400.000 IOPS seja atingido.

Por outro lado, a documentação da série Ddsv6 oferece até 400.000 IOPS e 12.000 MB/s. Isso torna as gerações V6 e mais recentes estrategicamente importantes para designs que precisam alinhar a computação e o armazenamento em torno das classes de desempenho de armazenamento mais altas.

A lição é simples: o desempenho máximo do banco de dados é uma propriedade de ponta a ponta, não uma propriedade somente armazenamento.

Planejar ciclos de negócios, não apenas estado estável

Muitos sistemas não têm um único perfil de desempenho. Eles têm vários:


Tráfego normal durante a semana.	Horário comercial de pico.
Processamento de fim de mês ou trimestre.	Feriado ou demanda sazonal.
Eventos de inicialização do produto.	Janelas de relatórios.
Janelas de manutenção.	Períodos de ingestão do Lote do Azure.
Cenários de backup e restauração.	Eventos de recuperação de desastre.

Um banco de dados dimensionado para utilização média pode ter dificuldades durante os momentos mais importantes. Por outro lado, um banco de dados dimensionado permanentemente para um pico uma vez por mês pode ser desnecessariamente caro.

A flexibilidade do Azure permite que as equipes façam escolhas mais matizadas. Por exemplo:

Use o SSD Premium v2 para ajustar o IOPS e a taxa de transferência à medida que a carga de trabalho precisa evoluir.
Use réplicas de leitura para descarregar cargas de trabalho de leitura pesada, quando apropriado.
Dimensionar a computação para períodos de pico conhecidos.
Ajuste consultas, índices e pool de conexões antes de dimensionar a infraestrutura.
Use a observabilidade para identificar se o gargalo é CPU, memória, IOPS, taxa de transferência, contenção de bloqueio, pressão de conexão ou design de consulta.

A melhor implantação nem sempre é a maior implantação. É o design que corresponde à carga de trabalho e pode evoluir com segurança.

A observabilidade faz parte da arquitetura

O planejamento de desempenho não deve parar na implantação. As cargas de trabalho do Postgres são alteradas ao longo do tempo. Os dados crescem, os padrões de consulta mudam, novos recursos são lançados, o tráfego de clientes muda, e os trabalhos operacionais se acumulam.

Área de monitoramento	Sinais para revisão
Computação	Utilização da CPU e pressão de memória.
Connections	Conexões ativas, conexões ociosas e comportamento do pool de conexões.
Consultas	Duração da consulta, alterações de plano de consulta e uso de índice.
Armazenamento	Porcentagem de armazenamento, latência de leitura, latência de gravação, utilização de IOPS e estatísticas de taxa de transferência.
Maintenance	Inchaço de tabela, inchaço de índice, características do WAL, cronogramas de backup e manutenção.
Replication	Retardo de réplica, quando relevante.

A documentação do Banco de Dados do Azure para PostgreSQL destaca o monitoramento do consumo de E/S por meio do portal do Azure ou de métricas do CLI do Azure, incluindo limite de armazenamento, percentagem de armazenamento, armazenamento usado e percentagem de E/S.

Essas métricas ajudam a responder à pergunta operacional mais importante: qual camada está realmente limitando o desempenho?

Sem observabilidade, as equipes podem dimensionar a coisa errada. Um problema de plano de consulta pode parecer um problema de armazenamento. Tempestades de conexão podem parecer resultar em pressão sobre a CPU. Um índice ausente pode parecer IOPS insuficiente. Um problema de alocação regional de cliente pode parecer um problema de latência de banco de dados.

O monitoramento ajuda as equipes a fazer alterações direcionadas em vez de palpites caros.

Lista de verificação de planejamento prático

Antes de selecionar a configuração de produção do Banco de Dados do Azure para PostgreSQL, capture as informações a seguir.

Category	Insumos de planejamento
Tipo de carga de trabalho	OLTP, OLAP, híbrido, relatório, lote e ingestão.
Combinação de leitura/gravação	Porcentagem de leituras, porcentagem de gravações, E/S aleatória e E/S sequencial.
Desempenho atual	IOPS de linha de base, taxa de transferência, latência, CPU, memória e conexões.
Desempenho de pico	Requisitos de carga de trabalho do 90º e do 99º percentil.
Tamanho dos dados	Tamanho atual, crescimento esperado, uso de objetos grandes e crescimento de índice.
Taxa de crescimento	Projeções de armazenamento mês a mês e ano a ano.
Concurrency	Sessões ativas, sessões ociosas e comportamento do pool de conexões.
Ciclos de negócios	Picos diários, semanais, mensais, sazonais e impulsionados por lançamentos.
Disponibilidade	Alta disponibilidade, réplicas, recuperação de desastre, backup, restauração, RPO (objetivo de ponto de recuperação) e RTO (objetivo de tempo de recuperação).
Opção de armazenamento	SSD Premium, SSD Premium v2, regiões com suporte e recursos compatíveis.
Impacto no cache	Aplica-se o cache de host do SSD Premium v1 para volumes abaixo de 4 TB?
Geração de computação	Se o SKU selecionado pode fornecer os IOPS e a taxa de transferência necessários.
Modelo de dimensionamento	Dimensionamento manual, dimensionamento agendado, ajuste de desempenho e réplicas.
Observability	Métricas, alertas, insights de consulta e processo de revisão de carga de trabalho.

Princípios de design recomendados

Adote os seguintes princípios ao planejar implantações do Azure Postgres para desempenho operacional.

Dimensione segundo o perfil de carga de trabalho, e não apenas o tamanho dos dados.
Um banco de dados de 500 GB pode precisar de mais IOPS do que um banco de dados de 5 TB se for altamente transacional e sensível à latência. O tamanho é importante, mas o comportamento da carga de trabalho importa mais.
Valide a computação e o armazenamento juntos.
Não escolha o armazenamento com base apenas nos limites de disco. Confirme se a SKU de computação selecionada pode suportar os IOPS e a taxa de transferência necessárias.
Trate o limite de cache do SSD Premium de 4 TB como um marco de design.
Implantações de SSD Premium com menos de 4 TB podem se beneficiar do cache de host. Com 4.096 GB ou mais, não há suporte para cache de host. Se o crescimento ultrapassar esse limite, planeje o modelo de desempenho futuro mais cedo.
Considere o SSD Premium v2 para ajuste de desempenho flexível.
O SSD premium v2 permite um controle mais granular de capacidade, IOPS e taxa de transferência. Pode ser uma escolha forte quando as necessidades de desempenho não correspondem claramente aos tamanhos de disco fixos.
Use o bursting para intermitências, não a demanda sustentada.
O bursting pode ajudar com picos de curta duração, mas o bursting frequente ou sustentado geralmente significa que a configuração da linha de base deve ser revisitada.
Combinar a geração à ambição.
Para metas de desempenho de alto nível, as gerações de computação mais recentes, como a série v6, podem expor limites de armazenamento remoto agregados mais altos do que as gerações anteriores de uso geral. Se o alvo for uma arquitetura da classe de 400.000 IOPS, selecione a geração de processamento adequadamente.
Medida antes e depois das alterações.
O dimensionamento é mais fácil na nuvem, mas a medida é o que torna o dimensionamento eficaz. Capture as métricas de linha de base, pico e pós-alteração para que as decisões de desempenho sejam baseadas em evidências.

Parâmetro de comparação do mundo real: comparar as configurações de armazenamento sob carga

Os princípios descritos neste artigo não são teóricos. Para demonstrar como a computação, o armazenamento e a carga de trabalho interagem na prática, esta seção resume os parâmetros pgbench de comparação das configurações de armazenamento e das camadas de computação em condições controladas e medidas.

Configuração e metodologia de parâmetro de comparação

Os parâmetros de comparação usam pgbench, a ferramenta de parâmetro de comparação padrão do PostgreSQL, para simular uma carga de trabalho transacional em cinco configurações diferentes de armazenamento e computação. O teste começa com 500 conexões simultâneas e aumenta até 750 conexões simultâneas após um período inicial, mantendo essa carga de conexão elevada para o restante da janela de teste. Esse padrão de ramp-up simula quantos aplicativos reais aumentam a carga ao longo do tempo à medida que o tráfego aumenta e mede como o banco de dados responde ao pico inicial e à alta simultaneidade sustentada.

Todos os benchmarks são executados no Banco de Dados do Azure para PostgreSQL Flexible Server na mesma região, dentro da mesma zona de disponibilidade, usando o mesmo banco de dados de teste e perfil de carga de trabalho. Ao isolar o armazenamento e a computação como variáveis, você garante que as diferenças de desempenho reflitam os recursos reais da plataforma em vez da variação de rede, aplicativo ou carga de trabalho.

Detalhes da configuração

Teste cinco configurações distintas, variando a camada de armazenamento e o tamanho da computação para ilustrar os principais conceitos de planejamento.

Configuration	SKU de computação	vCores	Memória	IOPS de computação máxima	Tipo de armazenamento	Capacity	IOPS	Produtividade
Configuração 1	Standard_D16ds_v5	16	64 GB	25.600 (40.000 de intermitência)	SSD Premium (P50)	4\.095 GB	7,500	250 MB/s
Configuração 2	Standard_D16ds_v5	16	64 GB	25.600 (40.000 de intermitência)	SSD Premium (P50)	4.096 GB	7,500	250 MB/s
Configuração 3	Standard_D16ds_v5	16	64 GB	25.600 (40.000 pico)	SSD Premium (P80)	32 TB	20,000	900 MB/s
Configuração 4	Standard_D16ds_v5	16	64 GB	25.600 (40.000 de intermitência)	SSD Premium v2	4\.095 GB	40,000	1.200 MB/s
Configuração 5	Standard_D32ds_v5	32	128 GB	51.200	SSD Premium v2	4\.095 GB	60.000	1.200 MB/s

Principais observações do design de configuração:

Configuração 1 vs. Configuração 2: Essas configurações diferem apenas no tamanho de armazenamento, 4.095 GB contra 4.096 GB. Essa comparação testa o limite de cache do host para discos Premium SSD v1.
Configuração 2 vs. Configuração 3: Ambas as configurações usam o SSD v1, mas o Config 3 é dimensionado para a capacidade de 32 TB para desbloquear IOPS e taxa de transferência mais altas.
Configuração 3 vs. Configuração 4: Ambas as configurações usam a mesma computação, mas o Config 4 demonstra iOPS flexível do SSD premium v2 e taxa de transferência independente da capacidade.
Configuração 4 vs. Configuração 5: a configuração 5 dobra o SKU de computação para demonstrar como a computação de camada superior desbloqueia maior margem de desempenho de armazenamento.

Resultados de desempenho

Configuração 1: SSD Premium de 4.095 GB v1 com cache de host

A configuração 1 usa o tamanho do SSD Premium v1 de 4.095 GB, que se beneficia do cache de host no SSD Premium v1. Durante a carga de trabalho, essa configuração suportou:

IOPS máximo: 24.773, limitado por 7.500 IOPS provisionados no SSD Premium v1, com o cache ampliando o desempenho efetivo.
IOPS de leitura máxima: 21.330, beneficiando-se do cache de host para operações de leitura pesada.
IOPS de gravação máxima: 7.610.

O cache de host fornece amplificação de leitura, portanto, a IOPS efetiva excede momentaneamente o limite provisionado de 7.500 IOPS do disco e atinge os limites de armazenamento dos recursos de processamento.

Configuração 2: SSD Premium de 4.096 GB v1 sem cache de host

A configuração 2 usa o tamanho de SSD Premium v1 de 4.096 GB, ultrapassando o limite de cache e perdendo os benefícios de cache do sistema host. O impacto é visível:

IOPS máximo: Menor IOPS efetivo em comparação com a Configuração 1 devido à perda de cache.
IOPS de leitura máxima: Significativamente reduzido sem cache de host.
IOPS de gravação máxima: 7.610, inalterado.

Essa configuração demonstra a importância prática do limite de cache de 4 TB. A passagem de 4.095 GB para 4.096 GB altera o perfil de desempenho removendo leituras armazenadas em cache. Para bancos de dados crescentes que se aproximam desse limite, planeje com antecedência.

Configuração 3: SSD Premium de 32 TB v1 com IOPS mais alta

A configuração 3 aborda o IOPS superior do SSD Premium v1 e os limites de taxa de transferência escalando para capacidade de 32 TB. Essa configuração foi obtida:

IOPS máximo: 20.000.
IOPS de leitura máxima: Aproximadamente 12.000.
IOPS de gravação máxima: Aproximadamente 5.000.

Aumentar a capacidade de armazenamento do SSD Premium v1 subjacente aumenta a IOPS e a taxa de transferência. Você ainda pode atingir os limites superiores do intervalo de armazenamento de computação para cargas de trabalho intensivas.

Configuração 4: SSD Premium v2 com 40.000 IOPS

A configuração 4 demonstra a configuração de desempenho flexível do SSD Premium v2, provisionando 40.000 IOPS e taxa de transferência de 1.200 MB/s em 4.095 GB de capacidade:

IOPS máximo: Maior utilização efetiva devido à latência e à capacidade de taxa de transferência do SSD Premium v2.
IOPS de leitura máxima: Desempenho aprimorado em comparação com as configurações do SSD Premium v1.
IOPS de gravação máxima: Maior capacidade de gravação sustentada.

O SSD Premium v2 permite o provisionamento de IOPS alto sem a necessidade de uma grande capacidade de armazenamento, tornando-o eficiente para cargas de trabalho pesadas de transações.

Configuração 5: SSD Premium v2 com 60.000 IOPS na instância de computação D32ds_v5

A Configuração 5 escala tanto o desempenho de armazenamento, atingindo 60.000 IOPS, quanto a capacidade de computação, utilizando Standard_D32ds_v5 com 32 vCores. Essa configuração demonstra o princípio de alinhamento de ponta a ponta:

IOPS máximo: Significativamente maior do que todas as configurações anteriores.
IOPS de leitura máxima: Melhoria forte com espaço extra para computação.
IOPS de gravação máxima: Capacidade de gravação mais alta sustentada.

Ao alinhar a computação e o armazenamento a camadas de desempenho mais altas, essa configuração obtém a melhor taxa de transferência e a menor pressão da CPU. O teto de armazenamento mais alto de D32ds_v5 permite que o disco SSD premium V2 de 60.000 IOPS seja mais usado.

Lições dos parâmetros de comparação

Estas cinco configurações ilustram os principais princípios deste artigo:

O limite de cache de 4 TB é importante.
A configuração 1 vs. configuração 2 mostra que o cache de host fornece amplificação de desempenho de leitura mensurável abaixo de 4 TB, enquanto a passagem para 4.096 GB remove esse benefício.
Capacidade não é desempenho.
A configuração 3 provisionou 32 TB, mas não entregou o IOPS mais alto. Somente a capacidade de armazenamento não determina a taxa de transferência da transação.
O SSD Premium v2 fornece ajuste flexível de desempenho.
A configuração quatro demonstrou alta IOPS em capacidade modesta, validando o modelo desacoplado habilitado pelo SSD Premium v2.
A computação e o armazenamento devem ser alinhados.
A configuração cinco mostra que maximizar o desempenho do armazenamento requer espaço suficiente para computação. O teto de armazenamento mais alto de D32ds_v5 era necessário para usar mais plenamente a provisão de 60.000 IOPS.

Os resultados do parâmetro de comparação validam o princípio principal: o desempenho máximo é uma propriedade de ponta a ponta. Nenhuma única camada, como armazenamento, computação ou rede, determina o resultado. O sucesso requer alinhamento intencional em todas as camadas, validação medida e observação contínua à medida que as cargas de trabalho evoluem.

Conclusion

Azure Postgres fornece uma plataforma poderosa e flexível para criar soluções de banco de dados modernas hospedadas na nuvem. A engenharia no Azure em Computação, armazenamento, rede, alta disponibilidade, replicação, segurança e observabilidade habilita algumas das arquiteturas Postgres mais eficientes e resilientes disponíveis.

O desempenho máximo não ocorre por acidente.

O desempenho operacional máximo requer a compreensão do aplicativo, dos clientes, da carga de trabalho, do perfil de crescimento de dados, do mix de leitura/gravação e dos ciclos de negócios que moldam a demanda. Ele também requer o alinhamento de opções de computação e armazenamento para que as metas de IOPS, taxa de transferência e latência sejam alcançadas de ponta a ponta.

O SSD Premium v1 pode fornecer um forte desempenho previsível, especialmente quando o cache de host se aplica a dados abaixo do limite de 4 TB. O SSD Premium v2 adiciona uma configuração de desempenho mais flexível, desassociando capacidade, IOPS e taxa de transferência. O Ultra Disk representa a classe de desempenho de disco gerenciada mais alta Azure, enquanto as gerações de computação mais recentes fornecem tetos de armazenamento remoto agregados substancialmente mais altos para arquiteturas high-end.

As melhores implantações de Postgres no Azure combinam a capacidade da plataforma com planejamento deliberado, monitoramento contínuo e claro domínio operacional. Com os requisitos corretos e a arquitetura certa, as equipes podem oferecer experiências de Postgres de classe mundial que fornecem desempenho de pico.

Comentários

Esta página foi útil?

Last updated on 2026-05-08