Planear implementações do Azure Database para PostgreSQL para o desempenho operacional

A computação em nuvem remodelou drasticamente o panorama de alojamento de bases de dados. Dá às equipas acesso a escalabilidade, resiliência, alcance global e capacidades que antes eram inalcançáveis. Em vez de incorrerem em custos e custos gerais consideráveis ao planear a maior carga de trabalho possível (e suportar esse custo desde o primeiro dia), as equipas podem agora otimizar em torno da escala precisa de que precisam, quando precisam e ajustar-se conforme as suas exigências mudam.

Introduction

A flexibilidade para escolher o equilíbrio adequado de recursos é especialmente valiosa para implementações de bases de dados PostgreSQL. As cargas de trabalho de bases de dados PostgreSQL podem começar de forma pequena, crescer rapidamente, disparar sazonalmente, passar de muita leitura para muita escrita, ou evoluir de cargas de trabalho transacionais para sistemas híbridos operacionais e analíticos em tempo real. O Base de Dados do Azure para PostgreSQL garante que as suas soluções atingem os seus objetivos, oferecendo uma vasta gama de opções em computação, armazenamento, disponibilidade, replicação, segurança, backup e gestão operacional.

Mas com todo este poder vem a responsabilidade, especialmente ao planear as tuas missões. Para alcançar o melhor desempenho possível, as suas decisões de implementação devem corresponder aos requisitos globais da sua carga de trabalho.

Uma implementação bem-sucedida no Base de Dados do Azure para PostgreSQL não é apenas uma questão de escolher "o maior número de núcleos e memória de que precisamos." Em vez disso, o desempenho operacional máximo vem da compreensão dos comportamentos da sua aplicação, do cliente, das características de computação, armazenamento e crescimento da base de dados, e de como tudo isso se cruza e interage.

A melhor arquitetura é aquela em que estas peças estão intencionalmente alinhadas.

O planeamento do desempenho na cloud é uma responsabilidade partilhada

Um dos principais benefícios de migrar para uma plataforma cloud de confiança é o modelo de responsabilidade partilhada. A Microsoft fornece a infraestrutura global, serviços geridos, inovação em hardware, fiabilidade, segurança e engenharia operacional. As suas equipas trazem a experiência específica do contexto da aplicação: criticidade de negócio, comportamento da carga de trabalho, design do modelo de dados, perfil de tráfego de rede, expectativas de crescimento, objetivos de recuperação e requisitos de experiência do utilizador final.

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

O Azure oferece uma infraestrutura Postgres altamente escalável, mas a sua equipa deve trazer insights para estas áreas:

• Quantos utilizadores simultâneos são esperados durante os períodos normais e de pico?
• As operações mais importantes são de leitura intensiva, de escrita intensa ou mistas?
• A procura aumenta durante o final do mês, o final do trimestre, os feriados, os lançamentos ou as janelas de reporte?
• Quão rápido está a crescer o conjunto de dados?
• Quais operações são sensíveis à latência?
• Que consultas ou trabalhos toleram 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 da base de dados, distribuídos globalmente ou concentrados numa única geografia?

Capturar estes detalhes antes do lançamento, não após um incidente de produção. As implementações na cloud facilitam a escalabilidade, mas os designs mais eficazes e económicos continuam a começar com uma recolha sólida de requisitos e um planeamento adequado. Na maioria dos casos, estas questões podem ser resumidas às relações entre ligações concorrentes, IOPS máximo e throughput necessário.

O desempenho tem múltiplas camadas

O desempenho da base de dados raramente é determinado por uma única definição. As experiências de implementação bem-sucedidas dependem de várias camadas a trabalharem em conjunto:

• Desempenho na camada de aplicação.
  Esta camada inclui código de aplicação, padrões de consulta, cobertura de índice, uso de triggers, particionamento de dados, gestão de conexões, cacheamento, lógica de nova tentativa, pooling, comportamento ORM, design de transações e comportamento de tarefas em segundo plano.
• Desempenho da camada do cliente e da rede.
  Esta camada inclui onde os clientes estão localizados, como se ligam, se os pedidos cruzam regiões e zonas de disponibilidade, latência de rede, overhead TLS, rotatividade de ligação e se a aplicação utiliza o pooling de ligações de forma eficiente.
• Desempenho da plataforma de bases de dados.
  Esta camada inclui configuração de implementação do Postgres, tamanho de computação, memória, CPU, tipo de armazenamento, tamanho de armazenamento, IOPS de armazenamento, throughput de armazenamento, alta disponibilidade, réplicas e operações de manutenção.

Este artigo foca-se principalmente na terceira camada: planear a implementação da base de dados Azure Postgres de modo a que as escolhas de computação e armazenamento suportem o perfil de desempenho necessário.

O Base de Dados do Azure para PostgreSQL oferece flexibilidade, mas o planeamento é essencial

Base de Dados do Azure para PostgreSQL Flexible Server oferece uma vasta gama de opções de implementação, incluindo:

Esta flexibilidade é poderosa porque diferentes cargas de trabalho exigem capacidades distintas. Um sistema transacional com muita escrita não precisa do mesmo perfil que um sistema com muitos relatórios. Uma aplicação SaaS global não precisa do mesmo design que uma aplicação regional interna. Uma base de dados que cresce 5% por ano não precisa do mesmo plano de armazenamento que uma que cresce 200% mês após mês.

O objetivo do planeamento é identificar as necessidades do seu perfil de desempenho da carga de trabalho e depois implementar as escolhas adequadas tanto em opções de computação como de armazenamento para entregar as suas soluções de ponta a ponta com sucesso.

Comece pelo perfil de carga de trabalho

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

O objetivo não é prever o futuro na perfeição. O objetivo é evitar desenhar às cegas.

Compreenda os três conceitos centrais de desempenho de armazenamento

O planeamento do desempenho do armazenamento no Azure normalmente resume-se a três conceitos relacionados mas distintos: IOPS, throughput e latência. Estes fatores são fundamentais para o planeamento do desempenho da aplicação.

IOPS

IOPS significa operações de entrada/saída por segundo. Mede quantas operações de leitura ou escrita a base de dados pode enviar para armazenamento por segundo.

O IOPS é especialmente importante para cargas de trabalho OLTP. Estes sistemas frequentemente realizam muitas pequenas leituras e escritas aleatórias, como inserções, atualizações, consultas de índice, leituras de pontos e transações curtas. Uma carga de trabalho transacional com milhares de utilizadores concorrentes pode necessitar de IOPS elevados mesmo que cada operação individual seja pequena.

Cenários mais comuns sensíveis ao IOPS incluem:

• Processamento de encomendas de alto volume
• Atualizações do perfil do utilizador
• Sistemas de inventário
• Ingestão de eventos
• Sistemas de pagamento ou faturação
• Aplicações SaaS altamente concorrentes

Throughput

O rendimento, por vezes chamado de largura de banda, mede quanto de dados pode ser lido ou gravado em armazenamento ao longo do tempo. É expresso em MB/s.

A taxa de transferência é relevante quando as operações movimentam grandes quantidades de dados. Consultas analíticas, backups, restaurações, trabalhos em lote, compilações de índices, análises de tabelas e fluxos de trabalho ETL podem exigir um alto rendimento mesmo que não exijam o maior IOPS.

Cenários comuns sensíveis ao rendimento incluem:

• Relatórios de consultas sobre tabelas grandes
• Importações ou exportações a granel
• Varreduras ao estilo armazém de dados
• Operações de backup e restauro
• Grandes operações de criação ou reconstrução de índices
• Processamento em lotes

Latência

A latência é o tempo que demora a concluir um único pedido de E/S. A baixa latência é essencial para operações de base de dados orientadas para o utilizador, especialmente quando muitas pequenas operações estão encadeadas numa transação.

Um sistema pode ter um IOPS teórico elevado, mas ainda assim parecer lento se a latência for elevada. Para cargas de trabalho Postgres, a latência de armazenamento pode afetar diretamente os tempos de resposta das consultas, o comportamento do commit das transações, o comportamento dos checkpoints e a resposta geral à aplicação.

IOPS, vazão e latência devem ser considerados em conjunto

O IOPS e a largura de banda estão ligados. Uma carga de trabalho que emite várias pequenas operações de 8 KiB pode gerar um elevado IOPS mesmo sem um alto rendimento. Uma carga de trabalho que emite grandes operações de vários MB pode gerar um alto processamento com IOPS mais baixo.

Uma forma simples de pensar nisso:

IOPS x tamanho de E/S = Débito

Para a Postgres, a implicação prática é que o planeamento do armazenamento da carga de trabalho deve basear-se no comportamento observado ou estimado da carga de trabalho, e não apenas no tamanho da base de dados. Por exemplo:

• Um sistema OLTP de alta concorrência pode precisar de mais IOPS e menor latência.
• Um sistema com muitos relatórios pode precisar de mais rendimento.
• Um sistema híbrido pode precisar de ambos, especialmente durante os ciclos de pico.
• Um sistema OLTP de alta concorrência pode precisar de mais IOPS e menor latência.
• Um sistema com muitos relatórios pode precisar de mais rendimento.
• Um sistema híbrido pode precisar de ambos, especialmente durante os ciclos de pico.

As suas escolhas de implementação afetam diretamente o desempenho do armazenamento

Um erro comum é definir o armazenamento para um valor de desempenho alvo sem considerar totalmente se o SKU de computação selecionado consegue alcançar os mesmos níveis de desempenho.

O desempenho do armazenamento no Azure tem múltiplas considerações. Estes detalhes incluem:

• O conjunto de capacidades de computação (limites máximos de IOPS de computação e throughput).
• 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 picos de IOPS acima dos limiares padrão).
• A capacidade de armazenamento IOPS.
• A capacidade de processamento de armazenamento.

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

Se a configuração de armazenamento pode fornecer 80.000 IOPS mas o SKU de computação só consegue gerir 20.000 IOPS, a implementação não entrega 80.000 IOPS. Por outro lado, se a geração de VM suportar altas IOPS mas o nível de armazenamento selecionado estiver limitado a um valor inferior, o nível de armazenamento torna-se o limite.

O planeamento de computação e armazenamento deve acontecer em conjunto.

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

O SSD Premium v1 é uma escolha comum para cargas de trabalho Azure Postgres de produção que necessitam de desempenho previsível e provisionado. Azure armazenamento SSD Postgres v1 suporta 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 beneficiam do cache do host. Azure Postgres suporta cache de host para discos SSD v1 menos de 4.096 GB. Qualquer disco provisionado até 4.095 GB pode beneficiar da cache do host. Uma vez que o armazenamento é provisionado a 4.096 GB ou mais, a cache do host deixa de ser suportada. Esse limite importa. Para implementações de SSD Premium v1 com menos de 4 TB, a cache pode melhorar o desempenho da leitura e reduzir a latência de leitura. Este cacheamento cria excelente eficiência custo-desempenho para cargas de trabalho intensivas em leitura ou mistas, que ficam abaixo do limite de cacheamento.

Porque é que o limite de 4TB é importante

Quando uma implementação de SSD Premium v1 ultrapassa o intervalo suportado pela cache, o perfil de desempenho pode mudar:

• As leituras já não beneficiam da cache do host.
• Mais operações de leitura vêm diretamente do disco subjacente.
• As leituras afetam os limites de IOPS e throughput do disco.
• Cargas de trabalho de leitura sensíveis à latência podem apresentar comportamentos diferentes.
• Uma configuração que antes era eficiente pode precisar de mais IOPS provisionados, maior rendimento, escalonamento de computação, ajuste de consultas ou uma opção de armazenamento diferente.

Ultrapassar os 4 TB não é mau, mas tens de planear para isso.

Se espera que uma base de dados cresça para além dos 4 TB, considere o estado futuro durante o design da arquitetura. Um design que tenha bom desempenho a 2 TB com cache pode precisar de um plano de desempenho diferente a 5 TB sem cache.

O burst ajuda com picos, mas não substitui a capacidade sustentada

As alocações de armazenamento SSD Premium v1 do Azure Postgres inferiores a 4 TB suportam rajadas de cache do anfitrião, o que pode ajudar em cenários como:

• Atividade de startup
• Trabalhos em lotes curtos
• Picos de tráfego
• Processamento no final do mês
• Aumentos temporários de carga de trabalho

Embora o disparo seja útil, use-o com cuidado. O bursting pode absorver picos temporários, mas não deve ser a base para uma demanda sustentada de carga de trabalho. Se a carga de trabalho frequentemente ultrapassa a linha base, é melhor provisionar um nível de desempenho superior, ajustar as definições de desempenho do armazenamento, escalar o cálculo ou redesenhar o padrão da carga de trabalho.

Uma boa questão de planeamento é: Isto é um pico temporário ou é o novo normal?

Picos temporários podem ser bons candidatos para rebentar. Lidar com a procura sustentada através de um planeamento cuidadoso da capacidade.

O SSD premium v2 desacopla capacidade, IOPS e rendimento

O SSD premium v2 altera o modelo de planeamento ao desacoplar o tamanho do disco, IOPS e rendimento. Base de Dados do Azure para PostgreSQL Flexible Server Premium SSD v2 suporta:

• Capacidade de 32 GB a 64 TB.
• Até 80.000 IOPS.
• Até 1,200 MB/s de taxa de transferência.
• Ajustes granulares de capacidade em incrementos de 1 GB.
• Capacidade de configuração flexível de IOPS e throughput.
• Latência inferior ao SSD Premium v1.
• Sem cache de hosts.

Esta mudança é uma grande alteração. Com o SSD Premium v1, o desempenho está mais ligado ao tamanho do disco. Com o SSD Premium v2, podes configurar o desempenho de forma mais direta em função da necessidade de carga de trabalho.

Por exemplo, uma base de dados com muita transação pode necessitar de altos IOPS sem precisar de uma grande quantidade de armazenamento. Azure Postgres oferece IOPS de base e throughput sem custos adicionais, com opções adicionais de IOPS e throughput disponíveis mediante pagamento. O SSD premium v2 oferece:

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

O SSD premium v2 é frequentemente apelativo quando precisa de um controlo mais preciso sobre custos e desempenho. Em vez de escalar a capacidade de armazenamento apenas para desbloquear desempenho, podes fornecer desempenho de forma mais intencional.

Ultra Disk (Versão Prévia): a classe de alto desempenho para discos do Azure

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

• 400.000 IOPS
• Débito de 10 000 MB/s
• Capacidade de 64 TB
• Alvos de design com latência submilissegundo
• Capacidade, IOPS e largura de banda configuráveis de forma independente

O armazenamento Ultra Disk foi concebido para gerar cargas de trabalho intensivas em IO, para bases de dados de topo, SAP HANA e sistemas com forte intensidade de transações. Esta nova oferta de armazenamento oferece desempenho topo de gama para as suas cargas de trabalho críticas. No entanto, a sua equipa deve considerar algumas capacidades chave de implementação, restrições regionais de disponibilidade e opções de configuração ao planear uma implementação:

• O autogrow de armazenamento não é suportado para servidores que usam Ultra Disk
• A encriptação de dados com chaves geridas pelo cliente não é suportada para servidores com Ultra Disk
• Os Ultra Disks não suportam cache de disco

É importante compreender as capacidades do Ultra Disk como parte do panorama mais amplo de desempenho do armazenamento do Azure. No entanto, deve validar a disponibilidade do serviço e o suporte para a sua carga de trabalho específica do Azure Postgres. Confirme com o seu representante da Microsoft se o Ultra Disk Preview está disponível para a sua implementação no Azure Postgres.

A conclusão prática: Ultra Disk representa a extremidade superior do desempenho do armazenamento do Azure, mas o seu design Postgres de ponta a ponta deve incluir combinações suportadas de forma comparável para o SKU de computação selecionado, região e nível de lançamento.

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

A geração de computação pode afetar significativamente o desempenho do armazenamento. Ao explorar o limite máximo de desempenho do armazenamento no Azure, evite o mal-entendido de que "grande computação" significa automaticamente "armazenamento máximo". Deve validar o SKU de computação selecionado em relação ao nível de armazenamento pretendido. Vamos ilustrar este ponto considerando duas gerações de computação de tamanho semelhante, Ddsv5 e Ddsv6:

A série Ddsv5 suporta Armazenamento Premium (com cache), SSD Premium v2 e Ultra Disk ao nível da família VM. No entanto, os limites agregados de armazenamento remoto da VM continuam a definir o teto do que essa VM pode gerar. Ddsv5-série oferece desempenho de armazenamento até 80.000 IOPS e 2.600 MB/s.

A Ddsv6série - oferece um envelope de armazenamento maior, chegando a 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 mudança geracional é importante para o design Postgres de alto desempenho. Se a sua arquitetura alvo exigir elevado desempenho de armazenamento, escolher uma geração de computação com um teto agregado de armazenamento mais baixo pode impedir que a implementação utilize toda a capacidade de armazenamento.

Exemplo: porque é que o alinhamento de ponta a ponta é importante

Considere uma carga de trabalho PostgreSQL com um objetivo aspiracional de armazenamento de 400.000 IOPS.

Na camada de disco, o Azure Ultra Disk suporta até 400.000 IOPS por disco. O SSD premium v2 suporta até 80.000 IOPS por disco, e designs agregados de maior capacidade podem necessitar de múltiplos discos ou abstração ao nível da plataforma, dependendo do suporte por parte do serviço.

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

Uma configuração da série V5 pode ter um teto de armazenamento mais baixo do que o alvo. Como mencionado anteriormente, os SKUs da série V5 suportam até 260.000 IOPS para o rendimento remoto de disco SSD Premium. Neste caso, escolher a camada de computação da série V5 para este alvo torna-se o fator limitante antes de atingir um alvo de 400.000 IOPS.

Em contraste, a documentação da série Ddsv6 oferece até 400.000 IOPS e 12.000 MB/s. Isso torna a série V6 e gerações mais recentes estrategicamente importantes para designs que precisam de alinhar computação e armazenamento com as classes de maior desempenho de armazenamento.

A lição é simples: o desempenho máximo da base de dados é uma propriedade de ponta a ponta, não apenas de armazenamento.

Planeie para ciclos de negócio, não apenas para o estado estacionário

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

Uma base de dados dimensionada para utilização média pode ter dificuldades nos momentos que mais importam. Por outro lado, uma base de dados dimensionada permanentemente para um pico mensal pode ser desnecessariamente dispendiosa.

A flexibilidade do Azure permite às equipas fazer escolhas mais nuançadas. Por exemplo:

• Utilize o SSD Premium v2 para ajustar o IOPS e a largura de banda à medida que as necessidades da carga de trabalho evoluem.
• Quando apropriado, utilize réplicas de leitura para descarregar cargas de trabalho intensivas em leitura.
• Escalar computação para períodos de pico conhecidos.
• Ajuste consultas, índices e pools de conexões antes de ampliar a infraestrutura.
• Use a observabilidade para identificar se o gargalo é CPU, memória, IOPS, throughput, contenção de bloqueios, pressão de conexão ou design de consultas.

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

A observabilidade faz parte da arquitetura

O planeamento de desempenho não deve ficar apenas na implantação. As cargas de trabalho do Postgres mudam com o tempo. Os dados crescem, os padrões de consulta mudam, novas funcionalidades são lançadas, o tráfego dos clientes muda e os trabalhos operacionais acumulam-se.

A documentação do Base de Dados do Azure para PostgreSQL destaca a monitorização do consumo de E/S através do portal Azure ou métricas de CLI do Azure, incluindo limite de armazenamento, percentagem de armazenamento, armazenamento utilizado e percentagem de I/O.

Estas métricas ajudam a responder à questão operacional mais importante: que camada está realmente a limitar o desempenho?

Sem observabilidade, as equipas podem escalar o elemento errado. Um problema de plano de consulta pode parecer um problema de armazenamento. Tempestades de ligação podem parecer pressão no processador. A ausência de um índice pode ser confundida com insuficiência de IOPS. Um problema de colocação regional de clientes pode manifestar-se como uma latência de base de dados.

A monitorização ajuda as equipas a fazer alterações direcionadas em vez de suposições dispendiosas.

Lista de verificação do planeamento prático

Antes de selecionar a configuração de produção do Base de Dados do Azure para PostgreSQL, recolha a seguinte informação.

Princípios de design recomendados

Utilize os seguintes princípios ao planear implementações do Azure Postgres para desempenho operacional.

• Tamanho para a forma da carga de trabalho, não apenas para o tamanho dos dados.
  Uma base de dados de 500 GB pode precisar de mais IOPS do que uma de 5 TB se for altamente transacional e sensível à latência. O tamanho importa, mas o comportamento da carga de trabalho é mais importante.
• Validar computação e armazenamento em conjunto.
  Não escolha armazenamento apenas com base nos limites do disco. Confirme que o SKU de computação selecionado consegue suportar IOPS e débito necessários.
• Trate o limite de cache do SSD Premium de 4 TB como um marco de design.
  Implementações de SSD premium com menos de 4 TB podem beneficiar da cache do host. Com 4.096 GB ou mais, a cache do host não é suportada. Se o crescimento ultrapassar esse limiar, planeie o modelo de desempenho futuro com antecedência.
• Considere o SSD Premium v2 para uma afinação de desempenho flexível.
  O SSD premium v2 permite um controlo mais detalhado da capacidade, IOPS e throughput. Pode ser uma boa combinação quando o desempenho necessário não se adequa claramente a tamanhos fixos de disco.
• Utilize rajadas para picos, não para a demanda contínua.
  Estourar pode ajudar com picos de curta duração, mas o estourar frequente ou sustentado geralmente significa que a configuração de base deve ser revisitada.
• Alinhar a geração com a ambição.
  Para objetivos de desempenho de alto nível, gerações de computação mais recentes, como a série v6, podem expor limites de armazenamento remoto agregado mais elevados do que as gerações anteriores de uso geral. Se o alvo for uma arquitetura de classe 400.000 IOPS, selecione a geração de computação em conformidade.
• Mede antes e depois das alterações.
  A escalabilidade é mais fácil na cloud, mas a medição é o que torna a escalabilidade eficaz. Capturar métricas de referência, pico e pós-alteração para que as decisões de desempenho sejam baseadas em evidências.

Benchmark do mundo real: compare configurações de armazenamento sob carga

Os princípios apresentados neste artigo não são teóricos. Para demonstrar como computação, armazenamento e carga de trabalho interagem na prática, esta secção resume pgbench benchmarks que comparam configurações de armazenamento e níveis de computação sob condições controladas e medidas.

Configuração e metodologia do benchmark

Os benchmarks utilizam pgbench, a ferramenta padrão de benchmarks PostgreSQL, para simular uma carga de trabalho transacional em cinco configurações diferentes de armazenamento e computação. O teste começa com 500 ligações concorrentes e aumenta para 750 ligações concorrentes após um período inicial, mantendo esta carga elevada de ligação durante o restante período de teste. Este padrão de aumento simula quantas aplicações reais aumentam a carga ao longo do tempo à medida que o tráfego cresce, e mede como a base de dados responde tanto ao pico inicial como à elevada concorrência sustentada.

Todos os benchmarks correm no Base de Dados do Azure para PostgreSQL Flexible Server na mesma região, dentro da mesma zona de disponibilidade, utilizando a mesma base de dados de teste e perfil de carga de trabalho. Ao isolar o armazenamento e a computação como variáveis, assegura que as diferenças de desempenho refletem capacidades reais da plataforma em vez de variações de rede, aplicação ou carga de trabalho.

Detalhes da configuração

Teste cinco configurações distintas, variando tanto o nível de armazenamento como o tamanho do computo para ilustrar conceitos chave de planeamento.

Observações-chave do desenho da configuração:

• Configuração 1 vs. Configuração 2: Estas configurações diferem apenas no tamanho de armazenamento, 4.095 GB contra 4.096 GB. Esta 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 SSD v1, mas a Configuração 3 escala para uma capacidade de 32 TB para permitir maior IOPS e throughput.
• Configuração 3 vs. Configuração 4: Ambas as configurações usam os mesmos recursos de computação, mas a Configuração 4 demonstra o SSD Premium v2 com IOPS flexível e débito independente da capacidade.
• Configuração 4 vs. Configuração 5: A Configuração 5 duplica o SKU de computação para demonstrar como uma computação de nível mais elevado pode desbloquear mais margem de desempenho de armazenamento.

Resultados de desempenho

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

A Configuração 1 utiliza o SSD Premium v1 de 4.095 GB, que beneficia da cache do host no SSD Premium v1. Durante a carga de trabalho, esta configuração manteve-se:

• Máximo de IOPS: 24.773, limitado por 7.500 IOPS provisionados no SSD Premium v1, com cache a amplificar o desempenho efetivo.
• IOPS máximo de leitura: 21.330, beneficiando da cache do host para operações intensivas em leitura.
• Valor máximo de IOPS: 7.610.

A cache do host fornece amplificação de leitura, pelo que os IOPS efetivos excedem momentaneamente o limite de 7.500 IOPS provisionados do disco e atingem os limites de armazenamento de computação.

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

A Configuração 2 utiliza o SSD Premium V1 de 4.096 GB, ultrapassando o limite de cache e perdendo as vantagens do cache do host. O impacto é visível:

• Máximo de IOPS: IOPS efetivo inferior comparado com a Configuração 1 devido à perda de cache.
• Max leitura IOPS: Consideravelmente reduzido sem a cache do host.
• Valor máximo de IOPS: 7.610, inalterado.

Esta configuração demonstra a importância prática do limite de cache de 4 TB. Passar de 4.095 GB para 4.096 GB altera o perfil de desempenho ao remover as leituras em cache. Para bases de dados em crescimento que se aproximam deste limiar, planeie com antecedência.

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

A Configuração 3 aborda os limites superiores de IOPS e largura de banda do Premium SSD v1, escalando para uma capacidade de 32 TB. Esta configuração conseguiu:

• Máximo de IOPS: 20.000.
• Max leitura IOPS: Aproximadamente 12.000.
• IOPS de escrita máxima: Aproximadamente 5.000.

Aumentar a capacidade de armazenamento do SSD Premium v1 subjacente aumenta o IOPS e o throughput. Ainda é possível atingir os limites superiores do intervalo de armazenamento computacional 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 Premium SSD v2, fornecendo 40.000 IOPS e uma largura de banda de 1.200 MB/s em 4.095 GB de capacidade.

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

O SSD Premium v2 permite provisionar IOPS elevados sem exigir grande capacidade de armazenamento, tornando-o eficiente para cargas de trabalho com muitas transações.

Configuração 5: SSD Premium v2 com 60.000 IOPS na computação D32ds_v5

A Configuração 5 escala tanto o desempenho de armazenamento, com 60.000 IOPS, como o computo, com Standard_D32ds_v5 e 32 vCores. Esta configuração demonstra o princípio do alinhamento de ponta a ponta:

• Máximo de IOPS: Significativamente mais alto do que todas as configurações anteriores.
• Max leitura IOPS: Melhoria significativa com margem de computação extra.
• IOPS de escrita máxima: Maior capacidade de escrita sustentada.

Ao alinhar tanto computação como armazenamento a níveis de desempenho superiores, esta configuração alcança o melhor rendimento e a menor pressão de CPU. O teto de armazenamento mais elevado da D32ds_v5 permite que o disco SSD Premium v2, com 60.000 IOPS, seja utilizado de forma mais completa.

Lições dos benchmarks

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

• O limite de cache de 4 TB é importante.
  Config 1 vs. Config 2 mostra que a cache do host proporciona amplificação mensurável do desempenho de leitura abaixo dos 4 TB, enquanto ultrapassar os 4,096 GB elimina esse benefício.
• Capacidade não é desempenho.
  A Config 3 provisionou 32 TB mas não entregou o IOPS mais alto. A capacidade de armazenamento por si só não determina a taxa de transferência de transações.
• O SSD premium v2 oferece uma afinação flexível de desempenho.
  A configuração quatro demonstrou IOPS elevados com capacidade modesta, validando o modelo desacoplado possibilitado pelo SSD Premium v2.
• Computação e armazenamento devem estar alinhados.
  A quinta configuração mostra que maximizar o desempenho de armazenamento requer capacidade computacional suficiente. O teto de armazenamento mais elevado de D32ds_v5 era necessário para aproveitar mais plenamente a provisão de 60.000 IOPS.

Os resultados do benchmark validam o princípio fundamental: o desempenho máximo é uma propriedade de ponta a ponta. Nenhuma camada única, 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.

Conclusão

O Azure Postgres oferece uma plataforma poderosa e flexível para construir soluções modernas de bases de dados alojadas na cloud. A engenharia em Azure Compute, armazenamento, redes, alta disponibilidade, replicação, segurança e observabilidade permite algumas das arquiteturas Postgres mais performantes e resilientes disponíveis.

O desempenho máximo não acontece por acaso.

O desempenho operacional máximo requer compreender a aplicação, os clientes, a carga de trabalho, o perfil de crescimento de dados, a combinação de leitura/escrita e os ciclos de negócio que moldam a procura. Também requer alinhar as escolhas de computação e armazenamento para que os objetivos de IOPS, débito e latência sejam alcançados de ponta a ponta.

O SSD premium v1 pode fornecer um desempenho forte e previsível, especialmente quando a cache do host se aplica a dados abaixo do limite de 4 TB. O SSD premium v2 adiciona uma configuração de desempenho mais flexível ao desacoplar capacidade, IOPS e rendimento. O Ultra Disk representa a maior classe de desempenho de disco gerido no Azure, enquanto gerações de computação mais recentes oferecem tetos agregados de armazenamento remoto substancialmente mais elevados para arquiteturas de topo.

As melhores implementações do Azure Postgres combinam capacidade de plataforma com planeamento deliberado, monitorização contínua e propriedade operacional clara. Com os requisitos certos e a arquitetura certa, as equipas podem oferecer experiências Postgres de classe mundial que proporcionam desempenho máximo.

Conteúdo relacionado

• Azure Armazenamento Premium: design para alto desempenho
• Azure disco a explodir
• Tamanhos das VMs das séries Ddv5 e Ddsv5
• Tamanhos de VM da série Ddsv6
• Opção de armazenamento SSD Premium no Base de Dados do Azure para PostgreSQL
• Opção de armazenamento Premium SSD v2 na Base de Dados Azure para PostgreSQL
• Tipos de disco gerenciado do Azure
• Monitorize métricas no Azure Database para PostgreSQL