Este documento fornece recomendações de implementação e carga de trabalho para dimensionar instâncias do AlloyDB para PostgreSQL para cargas de trabalho de processamento de transações online (OLTP) e processamento analítico online (OLAP).
Vista geral
Para ajudar a alcançar um melhor desempenho da base de dados, o AlloyDB para PostgreSQL oferece as seguintes funcionalidades incorporadas:
- Gestão de memória automática
- Autovacuum adaptável
- Definições de desempenho incorporadas otimizadas
- Atraso de replicação baixo
- Manutenção não disruptiva com tempo de inatividade inferior a um segundo para os nós do conjunto principal e sem tempo de inatividade para os nós do conjunto de leitura durante as operações de escalabilidade
A otimização da instância do AlloyDB for PostgreSQL para o desempenho inclui a gestão do seguinte:
- Dimensionar corretamente as instâncias do pool principal e de leitura
- Atualizar sinalizações que afetam o desempenho
Considerações sobre o tamanho
Antes de dimensionar a sua instância do AlloyDB for PostgreSQL, determine o seguinte:
- Tipo de carga de trabalho: OLTP, OLAP ou HTAP
- Requisitos de desempenho: requisitos de latência e débito
- Tamanho esperado dos dados: o tamanho dos dados que planeia armazenar no AlloyDB for PostgreSQL e o tamanho do conjunto de dados ativo
- Escala da sua carga de trabalho: um aumento ou um crescimento no tamanho dos dados ao longo do tempo
Cargas de trabalho OLTP
Pode implementar a sua base de dados AlloyDB para PostgreSQL como uma instância zonal (nó único) ou como uma instância de alta disponibilidade (dois nós em cada zona). Opcionalmente, também pode adicionar instâncias do conjunto de leitura e um cluster secundário noutra região para cargas de trabalho distribuídas geograficamente ou para recuperação de desastres (RD).
O AlloyDB para PostgreSQL é implementado através de uma arquitetura distribuída e à escala da nuvem com computação e armazenamento desagregados. As escritas são reconhecidas assim que os ficheiros de registos de escrita antecipada (WAL) são persistidos no armazenamento regional, enquanto a materialização de blocos é transferida para o armazenamento.
Da mesma forma, com a arquitetura de cache de vários níveis, os dados são automaticamente colocados entre a cache de buffer, a cache ultrarrápida e o motor de armazenamento inteligente. Devido a esta arquitetura de cache de vários níveis usada no AlloyDB for PostgreSQL, as operações de entrada e saída por segundo (IOPs) não são relevantes no contexto do AlloyDB for PostgreSQL para comparação com outros sistemas de base de dados.
No entanto, a utilização de transações por segundo (TPS)/transações por minuto (TPM) pode fornecer uma comparação significativa para compreender a quantidade de dados que o AlloyDB for PostgreSQL pode processar.
A métrica de dimensionamento principal é o TPS. Para estimar o tamanho necessário do AlloyDB para PostgreSQL, siga estes passos:
- Identifique a sua carga de trabalho existente. Se estiver a migrar do PostgreSQL autogerido ou de outras bases de dados comerciais, pode já ter o valor de TPS para a sua carga de trabalho existente.
- Analise as suas consultas. Identifique as consultas mais críticas na sua carga de trabalho e determine os respetivos requisitos de desempenho.
- Use uma ferramenta como o
HammerDB
ou opgbench
. Estas ferramentas ajudam a testar o desempenho do AlloyDB para PostgreSQL e a determinar se o tamanho da máquina satisfaz os seus requisitos de TPS. - Use o guia de testes de referência de OLTP do AlloyDB for PostgreSQL. Este guia fornece dados de desempenho para várias configurações do AlloyDB for PostgreSQL, para encontrar uma configuração que cumpra os seus requisitos de TPS.
- Escolha um tamanho adequado do AlloyDB para PostgreSQL. Tenha em conta o tamanho atual dos dados e as expetativas de crescimento futuras.
Diretrizes de tamanho da máquina
A tabela de exemplo seguinte mostra recomendações para dados com testes de referência TPC-C que têm uma relação de leitura/escrita de aproximadamente 65% de leituras e 35% de escritas. Ao dimensionar uma instância do AlloyDB for PostgreSQL, deve procurar ter uma utilização da CPU em estado estável de cerca de 60 a 70% para evitar a sobrecarga de agendamento do sistema operativo. Isto permite alguma margem para picos na utilização de recursos por parte das aplicações cliente.
vCPU/Mem | Intervalo de transações/segundo recomendado (30% em cache) |
Tamanho dos dados de trabalho recomendado (até 128 TB no total) |
max_connections recomendado |
---|---|---|---|
2 / 16GB | Até 1000 | Até 100 GB | 1000 |
4 / 32GB | Até 2500 | Até 250 GB | 2000 |
8/ 64GB | Até 4000 | Até 500 GB | 4000 |
16 / 128GB | Até 8000 | Até 1 TB | 5000 |
32 / 256GB | Até 14 000 | Até 3 TB | 5000 |
64 / 512GB | Até 20 000 | Até 8 TB | 5000 |
96 / 768GB | Até 25 000 | Até 16 TB | 5000 |
128 / 864GB | Superior a 20 000 | Até 32 TB | 5000 |
Tipos de implementação
Com base na sua carga de trabalho, pode implementar o AlloyDB para PostgreSQL apenas como uma instância principal ou como uma instância principal com um conjunto de leitura.
Apenas principal
Escolha a implementação apenas primária para as seguintes cargas de trabalho:
- Com muita escrita e pouca ou média leitura
- Consultas com muitas leituras e poucas escritas
- Leitura/escrita OLTP típica (60 a 70% de leituras, 30 a 40% de escritas).
Para mais informações sobre os tipos de máquinas, consulte a diretriz geral de tamanho da máquina.
Principal com instância de conjunto de leitura
Se optar por implementar uma instância principal com um conjunto de leitura, considere o seguinte:
- Se tiver leituras sensíveis à latência, considere descarregar as suas consultas de leitura para instâncias do conjunto de leitura. Pode configurar até 20 nós em todas as instâncias do conjunto de leitura. Para mais informações, consulte o artigo Crie uma instância de pool de leitura.
- Configure várias instâncias do conjunto de leitura, se tiver mais do que uma base de dados, por exemplo, CRM ou Finanças na mesma instância. A utilização desta estratégia ajuda a melhorar o desempenho da cache e das consultas.
- Pode dimensionar as instâncias do pool principal e de leitura de forma diferente com base nos seus requisitos. Para mais informações sobre as práticas recomendadas para instâncias do conjunto de leitura, consulte o artigo Práticas recomendadas para melhorar o desempenho e a disponibilidade do AlloyDB.
- Adicione mais do que um nó por instância do conjunto de leitura para alta disponibilidade.
- Ativar o motor colunar seletivamente em instâncias específicas do conjunto de leitura para o desempenho das consultas de leitura. Esta opção não requer a ativação do motor de colunas na instância principal.
Pondere usar funcionalidades incorporadas, como o consultor de índices, para ajudar a adicionar índices que podem melhorar o desempenho das consultas.
Cargas de trabalho OLAP
Para cargas de trabalho OLAP, a métrica de dimensionamento principal é o desempenho das consultas, especialmente as consultas que exigem análises completas de tabelas ou agregações. O AlloyDB para PostgreSQL inclui um motor de colunas integrado que ajuda a acelerar as consultas analíticas. A ativação do motor de colunas por predefinição consome 30% da memória e usa automaticamente dados de cache ultrarrápidos.
Para mais informações sobre a medição do desempenho de OLAP com o AlloyDB for PostgreSQL usando a carga de trabalho TPC-H, consulte o guia de testes de referência de OLAP do AlloyDB for PostgreSQL.
Tipos de implementação
Com base na sua carga de trabalho, pode implementar o AlloyDB para PostgreSQL apenas como uma instância principal ou como uma instância principal com um conjunto de leitura.
Apenas principal
Se implementar uma instância apenas primária, tenha em atenção o seguinte:
- Use esta implementação para transações com consultas analíticas (HTAP).
- Ative o motor de colunas para ajudar com as consultas OLAP.
- Pondere a implementação com uma máquina de 16 vCPUs ou mais que ofereça mais memória para armazenar dados em colunas.
Primário com pool de leitura
Se implementar uma instância principal com um conjunto de leitura, considere o seguinte:
- Se tiver muitas escritas e leituras analíticas sensíveis à latência com requisitos de atraso baixos, implemente a instância principal com a HA ativada e com instâncias do conjunto de leitura.
- Ative o motor de colunas em instâncias do pool de leitura onde executa as suas consultas analíticas.
- Configure várias instâncias do conjunto de leitura, se tiver mais do que uma base de dados, por exemplo, CRM ou Finanças na mesma instância. A utilização desta estratégia ajuda a melhorar o desempenho da cache e das consultas.
- Pode dimensionar as instâncias do pool principal e de leitura de forma diferente com base nos seus requisitos. Para mais informações sobre as práticas recomendadas para instâncias do conjunto de leitura, consulte o artigo Práticas recomendadas para melhorar o desempenho e a disponibilidade do AlloyDB.
- Adicione mais do que um nó por instância do conjunto de leitura para alta disponibilidade.
- Ativar o motor colunar seletivamente em instâncias específicas do conjunto de leitura para o desempenho das consultas de leitura. Esta opção não requer a ativação do motor de colunas na instância principal.
O que se segue?
- Saiba mais sobre as práticas recomendadas para melhorar o desempenho e a disponibilidade.
- AlloyDB para PostgreSQL para o guia de testes de referência OLTP do PostgreSQL.
- AlloyDB for PostgreSQL for PostgreSQL OLAP Benchmarking Guide.