Comparação de desempenho OLTP no AlloyDB para PostgreSQL

Este documento descreve como configurar o AlloyDB para PostgreSQL e uma máquina cliente para comparar o desempenho do AlloyDB usando o TPC-C, uma especificação de comparativo de mercado OLTP. Este documento também descreve como executar cenários personalizados de OLTP com uso intensivo de leitura e gravação, como Somente inserção de índice e Somente seleção.

As instruções neste documento são baseadas em uma configuração específica do AlloyDB e da máquina cliente. Use os valores fornecidos para cada etapa nas instruções de comparação de mercado.

Recursos de carga de trabalho do AlloyDB

O AlloyDB oferece confiabilidade, escalabilidade e desempenho de nível empresarial adequados para todas as empresas e cargas de trabalho críticas. O AlloyDB oferece os seguintes componentes e recursos que permitem alto desempenho para cargas de trabalho transacionais (OLTP), analíticas (OLAP) e híbridas (HTAP):

  • Gerenciamento de registros e transações
  • Gerenciamento de memória dinâmico
  • Integração de inteligência artificial e machine learning
  • Mecanismo colunar integrado
  • Um cache de várias camadas
  • Armazenamento distribuído e escalonável

Os sistemas de banco de dados relacional geralmente exigem que um administrador de banco de dados otimize o banco de dados para comparação de mercado, o que inclui configurar as configurações do registro de transações, estabelecer os tamanhos corretos do pool de buffer e modificar outros parâmetros ou sinalizações e características do banco de dados. Essas configurações variam de acordo com o tamanho e o tipo da instância.

O AlloyDB vem pré-configurado com configurações otimizadas para cada tipo de máquina. O AlloyDB não exige que você ajuste flags no nível do banco de dados para ter um alto desempenho de OLTP. Em vez disso, o AlloyDB tem um alto desempenho de OLTP integrado.

Tipos de comparativos disponíveis

Este documento mostra como executar comparativos de mercado OLTP usando as seguintes ferramentas:

Drivers de comparativo de mercado OLTP Casos de uso
HammerDB (link em inglês) O HammerDB mede o desempenho do sistema em termos de transações por minuto (TPM) e gera relatórios que incluem estatísticas detalhadas e métricas de desempenho.

O HammerDB oferece suporte à personalização de parâmetros de comparação de mercado, o que permite ajustar o tamanho do banco de dados, o número de armazéns e outras características de carga de trabalho para simular diferentes cenários.

O HammerDB inclui uma implementação de comparativo de mercado TPC-C para avaliar o desempenho dos sistemas OLTP. A implementação do TPC-C do HammerDB permite simular uma carga de trabalho semelhante ao comparativo de mercado TPC-C, incluindo uma combinação de transações que imitam o comportamento de um ambiente de fornecedor atacadista.
pgbench (link em inglês) O pgbench é uma ferramenta de comparação de mercado que vem com o PostgreSQL. O pgbench permite simular cargas de trabalho de transações, como inserir, atualizar, selecionar dados e medir o desempenho do sistema de banco de dados em transações por segundo (TPS, na sigla em inglês).

Ao usar o pgbench, é possível personalizar o tamanho do banco de dados, o número de clientes e a combinação de transações para emular a carga de trabalho de produção e receber insights sobre o comportamento do sistema em diferentes cenários.
O pgbench inclui uma implementação do TPC-B. A implementação do TPC-B do pgbench é semelhante a um comparativo de mercado TPC-B.

Antes de começar

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Ative as APIs do Cloud necessárias para criar e se conectar ao AlloyDB para PostgreSQL.

    Ativar as APIs

    1. Na etapa Confirmar projeto, clique em Próxima para confirmar o nome do projeto em que você vai fazer mudanças.

    2. Na etapa Ativar APIs, clique em Ativar para ativar o seguinte:

      • API AlloyDB
      • API Compute Engine
      • API Cloud Resource Manager
      • API Service Networking

      A API Service Networking é necessária se você planeja configurar a conectividade de rede ao AlloyDB usando uma rede VPC que reside no mesmo projeto do Google Cloud que o AlloyDB.

      A API Compute Engine e a API Cloud Resource Manager são necessárias se você planeja configurar a conectividade de rede ao AlloyDB usando uma rede VPC que reside em um projeto diferente do Google Cloud.

Configurar e provisionar o banco de dados e a máquina cliente

Comece o comparativo de mercado criando um cluster e uma instância do AlloyDB. A menos que especificado de outra forma, as informações neste documento são baseadas em uma vCPU de 16 com 128 GB de RAM como uma instância principal do AlloyDB.

Criar um cluster e uma instância do AlloyDB

  1. Acesse a página Clusters.

    Acessar Clusters

  2. Clique em Criar cluster.

  3. No campo ID do cluster, insira um nome para o cluster.

  4. Em Disponibilidade por zona, selecione Várias zonas (altamente disponível) para o tipo de cluster.

  5. Selecione a rede padrão.

  6. No campo Versão do banco de dados, selecione PostgreSQL 15.

  7. Anote o local da zona principal e do endereço IP particular. Não crie um pool de leitura.

  8. Clique em Criar cluster.

Provisionar a máquina cliente

Para executar comparativos de mercado OLTP, você precisa de uma máquina cliente com capacidade de processamento adequada. Ferramentas de comparação de mercado, como HammerDB e pgbench, são executadas de maneira altamente paralela e consomem muita CPU. Uma máquina cliente não pode ser um gargalo quando você executa um comparativo de mercado OLTP.

A menos que especificado de outra forma, as instruções neste documento usam uma máquina E2-standard-32 com disco de 128 GB como cliente para comparativos de mercado OLTP para gerar uma instância do AlloyDB em uma máquina de 16 vCPUs com 128 GB de RAM. É necessário criar a máquina cliente na mesma zona da instância principal do AlloyDB.

Para executar o comparativo de mercado TPC-C em uma instância principal do AlloyDB com 16 CPUs virtuais, siga estas etapas para criar uma VM do Compute Engine e provisionar uma máquina cliente:

  1. No console do Google Cloud, acesse a página Instâncias de VMs.

    Acessar instâncias de VM

  2. Selecione o projeto que contém a instância do AlloyDB à qual você quer se conectar.
  3. Clique em Criar instância.
  4. Clique na seção Configuração da máquina.
  5. Digite um Nome para a instância.
  6. Configure a zona em que você quer criar a instância. A zona precisa ser a mesma da instância principal do AlloyDB.
  7. Selecione um tipo de máquina e2-standard-32.
  8. Mantenha os valores padrão na seção SO e armazenamento.
  9. Clique na seção Rede e defina Interfaces de rede para a rede VPC configurada para acesso a serviços particulares ao AlloyDB.
    Se a opção Network interfaces não estiver definida como a rede VPC configurada para o acesso a serviços particulares, abra-a e defina Network como a rede VPC.
  10. Mantenha os valores padrão na seção Observabilidade.
  11. Clique na seção Segurança.
  12. Em Identidade e acesso à API, defina os Escopos de acesso como Permitir acesso total a todas as APIs do Cloud.
  13. Mantenha os valores padrão na seção Avançado.
  14. Clique em Criar.
  15. Depois que a VM for criada, conecte-se à VM do Compute Engine que você criou usando SSH.

Configurar a máquina de driver de comparação

Depois de instalar e configurar o banco de dados e a máquina cliente, configure a máquina cliente em execução em Google Cloud, onde você instala ferramentas de comparação como HammerDB e pgbench.

Para configurar a máquina de driver de comparativo de mercado, siga estas etapas:

  1. Conecte-se à máquina cliente usando o seguinte comando gcloud compute ssh:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME"  --project "GOOGLE_PROJECT"

  2. Instale o cliente PostgreSQL.

    1. Use o comando a seguir para instalar um cliente PostgreSQL que inclua um aplicativo psql e, em seguida, verifique se você consegue se conectar.

      sudo apt-get update
sudo apt install postgresql-client

    2. Use o comando abaixo para garantir que o cliente funcione e que você consiga se conectar ao AlloyDB. Use o endereço IP particular da sua instância principal do AlloyDB.

      psql -h PRIVATE_IP -U postgres

  3. Instale o driver HammerDB-4.6 para o comparativo de mercado TPC-C executando os seguintes comandos:

    mkdir hammerdb
pushd hammerdb
curl -OL https://github.com/TPC-Council/HammerDB/releases/download/v4.6/HammerDB-4.6-Linux.tar.gz
tar zxvf HammerDB-4.6-Linux.tar.gz

  4. Instale o driver pgbench para TPC-B e outros comparativos de mercado OLTP executando os seguintes comandos:

    sudo apt-get update
sudo apt-get install postgresql-contrib
pgbench --version

    Se o pgbench --version for executado sem erros, significa que o pgbench está instalado.

Realizar uma limpeza de comparativo de mercado

Se você planeja executar vários comparativos em sucessão, faça uma limpeza entre cada um deles para garantir resultados precisos e confiáveis.

A limpeza de comparativos de mercado garante que os efeitos residuais de comparativos de mercado anteriores não afetem as medições de desempenho do novo comparativo. A limpeza de valores de referência também ajuda a garantir a consistência e a repetição dos resultados do benchmark, o que é essencial para fazer comparações significativas entre diferentes sistemas ou identificar áreas para otimização em hardware, software ou configuração.

Siga estas etapas para realizar uma limpeza de comparativo de mercado antes de executar outro comparativo:

  1. Exclua os dados ou o banco de dados de comparação anteriores. Para excluir o banco de dados de comparativo de mercado anterior, use o seguinte comando psql na máquina cliente:

    psql -h PRIVATE_IP -U postgres -c "DROP DATABASE IF EXISTS <database_name>;"

    Para mais informações sobre o uso de psql, consulte Conectar a um banco de dados.

  2. Reinicie a instância do AlloyDB. Esta etapa limpa os caches no nível do banco de dados e do sistema operacional.

Executar um comparativo de mercado TPC-C

O HammerDB é uma ferramenta de comparativo de mercado que inclui uma implementação de comparativo de mercado TPC-C para avaliar o desempenho de sistemas OLTP. A implementação do TPC-C do HammerDB permite simular uma carga de trabalho semelhante ao comparativo de mercado TPC-C, incluindo uma combinação de transações que imitam o comportamento de um ambiente de fornecedor atacadista.

O HammerDB mede o desempenho do sistema em termos de transações por minuto (TPM) e gera relatórios que incluem estatísticas e métricas de desempenho detalhadas. Além disso, o HammerDB oferece suporte à personalização dos parâmetros de comparação, permitindo que os usuários ajustem o tamanho do banco de dados, o número de armazéns e outras características de carga de trabalho para simular diferentes cenários.

Cenários de avaliação de performance

A performance do comparativo de mercado TPC-C é avaliada usando os seguintes métodos:

  • Modo parcialmente (~30%) armazenado em cache:nesse modo, um grande banco de dados TPC-C é gerado, que pode caber apenas parcialmente no buffer de cache. As transações nesse modo não são sempre atendidas pela memória e geram E/S para os subsistemas de armazenamento subjacentes. Esse cenário é aplicável às necessidades de OLTP de muitos usuários.

  • Modo em cache totalmente (100%):nesse modo, o banco de dados TPC-C se encaixa totalmente no cache de buffer. A instância do AlloyDB usa aproximadamente 90% dos 128 GB de RAM disponíveis, incluindo o cache de buffer.

    Como as transações TPC-C executam E/S mínimas, porque as leituras são atendidas principalmente pelo cache de buffer, nesse modo, é esperado um TPM maior em comparação com execuções parcialmente armazenadas em cache. Esse cenário é aplicável às necessidades de OLTP de usuários com necessidades de E/S muito baixas.

Configurar a máquina cliente

  1. Configure a máquina de comparativo de mercado.

  2. Se você estiver executando vários comparativos em sucessão, faça uma limpeza de comparativos.

  3. Abra o hammerdb/HammerDB-4.6 directory executando o seguinte comando:

    cd hammerdb/HammerDB-4.6

    Você executa comandos neste diretório para configurar a máquina cliente.

  4. Crie o arquivo setup.env usando os seguintes comandos:

    cat << EOF > setup.env
# Private IP of the AlloyDB primary instance
export PGHOST=PRIVATE_IP
# Postgres default port address. You do not need to change it unless you use non-default port address.
export PGPORT=5432   # default port to connect with postgres
# Number of TPC-C warehouses to load. This determines the overall database size.
export NUM_WAREHOUSE=576
# Number of users for running the benchmark.
export NUM_USERS=256
EOF

  5. Edite o arquivo setup.env gerado substituindo todos os valores de parâmetros destacados pelos valores de parâmetro mais adequados à configuração do ambiente.

  6. Opcional: teste o modo parcialmente armazenado em cache (~30%) mudando NUM_WAREHOUSE para 3200 no arquivo setup.env. Para mais informações, consulte Cenários de avaliação de desempenho.

  7. Opcional: teste o modo de cache totalmente (100%) mudando NUM_WAREHOUSE para 576 no setup.env file. Para mais informações, consulte Cenários de avaliação de desempenho.

Carregar dados TPC-C no banco de dados

Uma etapa de carga se refere ao processo de preenchimento do banco de dados de comparação com dados iniciais antes de executar o teste de desempenho.

Durante a etapa de carregamento, o banco de dados é preenchido com um número especificado de armazéns, clientes e outras entidades de acordo com as especificações do TPC-C. O objetivo da etapa de carga é criar uma carga de trabalho realista para o teste de desempenho e garantir que os resultados do teste sejam comparáveis em diferentes sistemas.

Depois que a etapa de carga é concluída, o banco de dados fica em um estado consistente com um conjunto definido de dados iniciais, pronto para ser usado no teste de comparação de mercado TPC-C.

Para carregar o banco de dados TPC-C, siga estas etapas:

  1. Mude para o diretório principal de comparativo de mercado usando o seguinte comando:

    cd hammerdb/HammerDB-4.6

  2. Copie e cole o conteúdo a seguir em build-tpcc.sh:

    #!/bin/bash -x

source ./setup.env

# create role tpcc with superuser login as 'postgres' and password as 'AlloyDB#123';
# -----------------------------------------------------

./hammerdbcli << EOF

# CONFIGURE PARAMETERS FOR TPCC BENCHMARK
# --------------------------------------
dbset db pg
dbset bm tpc-c

# CONFIGURE POSTGRES HOST AND PORT
# --------------------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC
# --------------------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user tpcc
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# SET NUMBER OF WAREHOUSES AND USERS TO MANAGE EACH WAREHOUSE
# THIS IMPORTANT METRIC ESTABLISHES THE DATABASE SCALE/SIZE
# --------------------------------------
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 10

# LOG OUTPUT AND CONFIGURATION DETAILS
# --------------------------------------
vuset logtotemp 1
print dict

# CREATE AND POPULATE DATABASE SCHEMA
# --------------------------------------
buildschema

waittocomplete
vudestroy
quit

EOF

  3. Execute o comando de carregamento a seguir e aguarde a conclusão.

    chmod +x ./build-tpcc.sh
mkdir results
sudo nohup ./build-tpcc.sh > results/build-tpcc.out 2>&1

  4. Valide a carga. Depois que o script anterior for concluído, recomendamos que você confirme se o carregamento do banco de dados foi bem-sucedido. Para verificar o tamanho do banco de dados, execute o seguinte:

    psql -h $PGHOST -p 5432 -U postgres
postgres=> \l+ tpcc
                                                                          List of databases
     Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size   | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+---------+------------+--------------------------------------------
 tpcc         | tpcc             | UTF8     | C.UTF-8 | C.UTF-8 |                                       | --- GB  | pg_default |
           |                  |          |         |         |                                       | 160.000 |            |
 (1 row)

Em uma configuração TPC-C com 30% de cache (com 3.200 armazéns), o tamanho do banco de dados tpcc será de cerca de 300 GB.

Em uma configuração TPC-C com 100% de cache (com 576 armazéns), o tamanho do banco de dados tpcc será de aproximadamente 55 GB.

Executar a comparação TPC-C

Agora você já pode executar o teste de desempenho TPC-C. O comparativo TPC-C é executado usando o banco de dados preenchido da etapa de carga. O comparativo gera uma série de transações que simulam um ambiente de negócios típico, incluindo entrada de pedidos, processamento de pagamentos e gerenciamento de inventário. A carga de trabalho é medida em transações por minuto (TPM, na sigla em inglês), que representa o número de transações comerciais completas que o sistema pode processar em um minuto.

A etapa de execução foi projetada para estressar o sistema de banco de dados em condições reais e fornecer uma maneira padrão de medir o desempenho que pode ser comparada em diferentes sistemas de banco de dados. Os fornecedores e os usuários costumam usar os resultados do comparativo de mercado TPC-C para avaliar o desempenho de diferentes sistemas de banco de dados e configurações de hardware.

Para executar o comparativo de mercado TPC-C, siga estas etapas:

  1. Alterne para o diretório inicial de comparação:

    cd hammerdb/HammerDB-4.6

  2. Copie e cole o conteúdo a seguir em run-tpcc.sh:

    #!/bin/bash -x

source ./setup.env

./hammerdbcli << EOF
dbset db pg
dbset bm tpc-c

# CONFIGURE PG HOST and PORT
# -------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC DB
# -------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user postgres
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# BENCHMARKING PARAMETERS
# -------------------------
diset tpcc pg_driver timed
diset tpcc pg_rampup 10
diset tpcc pg_duration 60
diset tpcc pg_vacuum false
diset tpcc pg_partition false
diset tpcc pg_allwarehouse true
diset tpcc pg_timeprofile true
diset tpcc pg_connect_pool false
diset tpcc pg_dritasnap false
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 1

loadscript
print dict
vuset logtotemp 1
vuset vu $NUM_USERS
vucreate
vurun
waittocomplete
quit
EOF

  3. Execute o script usando os seguintes comandos:

    chmod +x run-tpcc.sh
mkdir results
sudo nohup ./run-tpcc.sh > results/run-tpcc.out 2>&1

  4. Aguarde a conclusão do script run-tpcc.sh. O script leva aproximadamente 1 hora e 10 minutos para ser concluído. Depois que o script terminar, você poderá analisar os resultados.

Analisar os resultados da comparação

No comparativo de mercado TPC-C, os novos pedidos por minuto (NOPM, na sigla em inglês) e as transações por minuto (TPM, na sigla em inglês) são métricas de desempenho usadas para medir o desempenho de um sistema de banco de dados.

  • NOPM:mede o número de novas transações de pedidos que o sistema pode processar em um minuto. A transação de novo pedido é uma das mais importantes no comparativo de mercado TPC-C e envolve a criação de um novo pedido para um cliente.

  • TPM:mede o número total de transações comerciais concluídas que o sistema pode processar em um minuto. As transações incluem novas transações de pedidos e outros tipos de transações definidas no comparativo de mercado TPC-C, como pagamento, entrega e status do pedido.

    O TPM é a principal métrica de desempenho do comparativo de mercado TPC-C porque oferece uma medida geral da capacidade do sistema de lidar com uma carga de trabalho realista. A NOPM pode ser uma métrica útil para sistemas focados no processamento de novos pedidos, como sistemas de e-commerce ou varejo.

Conferir os resultados com 30% do banco de dados TPC-C em cache em uma máquina de 16 vCPUs

Para extrair os números de desempenho para esse cenário, use o seguinte comando:

grep NOPM results/run-tpcc.out

A saída esperada é esta:

Vuser 1:TEST RESULT : System achieved 252970 NOPM from 582385 PostgreSQL TPM

Com 30% do banco de dados TPC-C em cache em uma máquina de 16 vCPUs (com NUM_WAREHOUSE=3200 e NUM_USERS=256), você observa 252.970 tpm-C (nova ordem por minuto) de um TPM cumulativo de 582.385 do AlloyDB.

Confira os resultados com um banco de dados TPC-C em cache de 100% em uma máquina de 16 vCPUs

Em um banco de dados TPC-C com cache de 100% em uma máquina de 16 vCPUs (com NUM_WAREHOUSE=576 e NUM_USERS=256), você observa 428.316 tpm-C (nova ordem por minuto) de um TPM cumulativo de 974.264 AlloyDB.

Para extrair os números de desempenho para este cenário, use o seguinte comando:

grep NOPM results/tpcc-run.out

A saída esperada é esta:

Vuser 1:TEST RESULT : System achieved 428316 NOPM from 974264 PostgreSQL TPM

Resumo dos resultados de desempenho em uma máquina com 16 vCPUs

A tabela a seguir resume os resultados de desempenho de comparativo de mercado para uma máquina de 16 vCPUs:

Cenário TPC-C NUM_WAREHOUSE NUM_USERS NOPM TPM cumulativo
30% em cache 3200 256 252.970 582.385
100% em cache 576 256 428.316 974.264

Observar as métricas de desempenho do banco de dados

Para entender melhor o comportamento do sistema de banco de dados, use as ferramentas de monitoramento do AlloyDB para observar métricas importantes do sistema, como uso da CPU, uso da memória e transações por segundo. Para mais informações, consulte Monitorar a performance da instância.

Por exemplo, depois de executar esse comparativo, é possível observar na página Visão geral do AlloyDB no console do Google Cloud que a utilização média da CPU para a execução TPC-C com 100% de cache é de quase 90%.

Executar um comparativo de mercado TPC-C em uma instância do AlloyDB com 64 vCPUs

Para executar um comparativo de mercado TPC-C em uma instância de 64 vCPU do AlloyDB, siga as mesmas etapas de configuração de Executar um comparativo de mercado TPC-C, mas use tipos de máquina diferentes.

Configurar o AlloyDB e a máquina cliente

  1. Crie um cluster e uma instância do AlloyDB, substituindo 64 vCPU, 512GB como o tipo de máquina.

  2. Provisione a máquina cliente, substituindo o n2-standard-64 como o tipo de máquina.

  3. Configure a máquina de comparativo de mercado.

Executar a comparação

  1. Se você estiver executando vários comparativos em sucessão, faça uma limpeza de comparativos.

  2. Configure a máquina cliente, substituindo os seguintes valores:

    • Defina PGHOST como o IP particular da sua nova instância do AlloyDB com 64 vCPUs.
    • Para o cenário TPC-C com 30% em cache, defina NUM_WAREHOUSE=12800 e NUM_USERS=1024.
    • Para o cenário TPC-C com 100% de cache, defina NUM_WAREHOUSE=2304 e NUM_USERS=1024.

  3. Configure e carregue um banco de dados TPC-C. Para acelerar o carregamento, mude o valor de pg_num_vu para 64 em build-tpcc.sh como diset tpcc pg_num_vu 64.

  4. Executar o comparativo de mercado TPC-C.

Analisar os resultados da comparação

A tabela a seguir resume os resultados de desempenho do comparativo de mercado em uma máquina de 64 vCPUs:

Modo de comparativo de mercado NUM_WAREHOUSE NUM_USERS NOPM TPM cumulativo
30% em cache 12800 1024 589.598 1.371.160
100% em cache 2304 1024 716.138 1.665.438

Executar um comparativo de mercado pgbench TPC-B

TPC-B (Transaction Processing Performance Council Benchmark B) é um dos modos de comparativo de mercado disponíveis no pgbench, uma ferramenta de comparativo de mercado para PostgreSQL. O TPC-B simula um cenário bancário em que vários caixas executam transações nas contas dos clientes. A carga de trabalho consiste nos seguintes tipos de transações:

  • Depósitos
  • Saques
  • Consultas de saldo

O comparativo de mercado mede o desempenho do sistema de banco de dados simulando uma combinação dessas transações e medindo o número de transações por segundo que o sistema pode processar.

O modo TPC-B no pgbench gera um banco de dados sintético e simula uma mistura de transações que se assemelha à carga de trabalho TPC-B, mas não é oficialmente certificada pela organização TPC. Portanto, embora o modo TPC-B no pgbench forneça uma aproximação útil do desempenho do TPC-B, não o use para declarar conformidade com os padrões TPC-B.

Cenários para medir a performance

Esta seção descreve como medir o desempenho do TPC-B nos seguintes modos críticos. O único parâmetro que é diferente nesses modos é o valor do parâmetro SCALE_FACTOR.

Cenário de banco de dados parcialmente armazenado em cache

Neste cenário, você configura e inicializa um banco de dados grande (aproximadamente 650 GB) usando --scale= 50000. Ter um banco de dados grande que não cabe na memória e causa E/S de disco significativa fornece uma representação realista de muitas cargas de trabalho de produção.

Um banco de dados grande que causa E/S de disco significativo pode enfatizar a importância do design do banco de dados e da otimização de consultas. Um banco de dados grande também pode expor problemas de desempenho relacionados à E/S de disco, como acesso lento ao disco ou consultas ineficientes, que podem não ser aparentes em um banco de dados pequeno ou totalmente residente na memória.

Cenário de banco de dados totalmente armazenado em cache

Neste cenário, você configura e inicializa um banco de dados de aproximadamente 60 GB usando --scale=4000 para que ele fique no pool de buffer. O comparativo de mercado de um banco de dados residente em memória é importante porque permite avaliar o desempenho máximo do sistema de banco de dados em um ambiente controlado.

Um banco de dados residente em memória armazena todos os dados no pool de buffer do PostgreSQL, eliminando o gargalo de E/S que pode ocorrer ao acessar dados do disco. Esse modo pode ajudar a identificar gargalos de desempenho que não estão relacionados à E/S, como problemas de uso da CPU ou de bloqueio, que podem não ser aparentes quando você compara um banco de dados que depende da E/S de disco.

Configurar o servidor de banco de dados e a máquina cliente

Para configurar a infraestrutura para executar um comparativo de mercado pgbench TPC-B, siga estas etapas:

  1. Crie um cluster e uma instância do AlloyDB, substituindo 16 vCPU, 128GB como o tipo de máquina.

  2. Provisione a máquina cliente, substituindo E2-standard-16 (minimum) como o tipo de máquina.

  3. Configure a máquina de comparativo de mercado.

  4. Faça uma limpeza de comparativo de mercado.

Executar o comparativo TPC-B do pgbench

  1. Conecte-se à máquina cliente usando o seguinte comando da CLI do Google Cloud:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. Crie o arquivo pgbench-setup.env:

    $ cat << EOF > pgbench-setup.env

# Private IP of the AlloyDB primary instance
export PGHOST=<private_ip>

# Set PGUSER to postgres as a default user.
export PGUSER=postgres

# Password set for PGUSER
export PGPASSWORD=<your pg password>

# In pgbench, the scale factor represents the size of the test database.
# and is defined as the number of 1 MB-sized data pages to be generated per client.
export SCALE_FACTOR=<scale_factor>

# Number of clients to drive the benchmark in throughput mode
export NUM_CLIENTS=<num_clients>

EOF

  3. Edite o arquivo setup.env gerado e substitua o valor do parâmetro a seguir por valores adequados à configuração do ambiente.

    • PRIVATE_IP: o IP particular da sua instância do AlloyDB.

    Use a tabela a seguir para escolher os valores <scale_factor> e <num_clients>. Esses valores precisam ser dimensionados de acordo com o tipo de máquina e o tamanho do banco de dados (totalmente armazenado em cache ou parcialmente armazenado em cache). Os exemplos neste guia usam valores SCALE_FACTOR e NUM_CLIENT correspondentes ao tipo de máquina n2-highmem-16.

    Totalmente em cache Parcialmente em cache
    Tipo de máquina SCALE_FACTOR NUM_CLIENTS SCALE_FACTOR NUM_CLIENTS
    n2-highmem-2 500 48 6250 32
    n2-highmem-4 1000 96 12500 64
    n2-highmem-8 2000 192 25.000 128
    n2-highmem-16 4000 384 50000 256
    n2-highmem-32 8.000 768 100000 512
    n2-highmem-64 16.000 1.536 200000 1024

  4. Criar um banco de dados do pgbench.

    source ./pgbench-setup.env
psql -h $PGHOST -p 5432
postgres=> create database pgbench;
CREATE DATABASE

  5. Inicie e carregue o banco de dados pgbench executando os comandos abaixo. Essa etapa garante que o conjunto de dados de comparação seja criado e preenchido com dados realistas, o que permite simular com precisão uma carga de trabalho TPC-B no banco de dados pgbench.

    source ./pgbench-setup.env
sudo nohup pgbench -i --host=$PGHOST --scale=$SCALE_FACTOR pgbench > /tmp/pgbench-tpcb-partially-cached-db-init.out 2>&1

    Tempos de carregamento esperados:

    • O banco de dados parcialmente armazenado em cache leva aproximadamente seis horas para carregar.
    • O banco de dados totalmente armazenado em cache leva aproximadamente 45 minutos para carregar.

  6. Opcional: faça uma verificação de precisão de carga, garantindo que o conteúdo do arquivo /tmp/pgbench-tpcb-partially-cached-db-init.out seja semelhante ao seguinte:

    generating data (client-side)...
100000 of 400000000 tuples (0%) done (elapsed 0.02 s, remaining 99.82 s)
.. .. ..
.. .. ..
399800000 of 400000000 tuples (99%) done (elapsed 534.60 s, remaining 0.27 s)
399900000 of 400000000 tuples (99%) done (elapsed 534.72 s, remaining 0.13 s)
400000000 of 400000000 tuples (100%) done (elapsed 534.85 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 1481.92 s (drop tables 0.01 s, create tables 0.04 s, client-side generate 540.93 s, vacuum 615.11 s, primary keys 325.84 s).

  7. Opcional: para validar ainda mais a precisão da carga, execute o seguinte comando do PostgreSQL que mede o tamanho de todas as tabelas do pgbench:

    1. Conecte-se ao banco de dados pgbench:

      source ./pgbench-setup.env
psql -h $PGHOST -p 5432 -U postgres -d pgbench

    2. Execute o seguinte comando SQL:

      pgbench=> SELECT nspname AS schema_name, relname AS table_name, pg_size_pretty(pg_total_relation_size(C.oid)) AS size FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema'
ORDER BY pg_total_relation_size(C.oid) DESC;

    3. Compare a saída do comando anterior com a saída que você recebeu para a execução do banco de dados parcialmente armazenada em cache (SCALE_FACTOR=50000).

       schema_name |                table_name                 |  size
 -------------+-------------------------------------------+---------
 public      | pgbench_accounts                          | 731 GB
 public      | pgbench_accounts_pkey                     | 105 GB
 public      | pgbench_tellers                           | 32 MB
 public      | pgbench_tellers_pkey                      | 11 MB
 public      | pgbench_branches                          | 2952 kB
 public      | pgbench_branches_pkey                     | 1112 kB
 .. .. ..
 public      | pgbench_history                           | 0 bytes
 .. .. ..
 (29 rows)

  8. Execute os comandos abaixo para simular a carga de trabalho de um sistema de contabilidade financeira executando uma série de transações envolvendo depósitos, transferências e pagamentos, o que permite medir o desempenho do banco de dados sob uma carga de trabalho pesada.

    source ./pgbench-setup.env
mkdir -p ~/results/alloydb/pgbench
sudo nohup pgbench --host=$PGHOST --builtin=tpcb-like --time=3900 --jobs=$NUM_CLIENTS --client=$NUM_CLIENTS --scale=$SCALE_FACTOR --protocol=prepared --progress=1 pgbench > ~/results/alloydb/pgbench/pgbench.run.out 2>&1

Analisar os resultados da comparação

Verifique a saída do comando anterior no arquivo ~/results/alloydb/pgbench/pgbench.run.out. O número de TPS precisa estar próximo dos números mostrados no banco de dados com cache total e nos cenários de banco de dados com cache parcial.

Resultados com um banco de dados totalmente armazenado em cache

A saída do último comando em Executar o comparativo de mercado TPC-B do pgbench deve ser semelhante ao seguinte, em que --scale=4000:

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 4000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 84819501
latency average = 17.654 ms
latency stddev = 6.963 ms
tps = 21747.831164 (including connections establishing)
tps = 21750.579718 (excluding connections establishing)

Para entender melhor o comportamento do sistema de banco de dados, monitore métricas do sistema, como uso da CPU, da memória e transações por segundo, usando o console do Google Cloud. Para mais informações, consulte Monitorar instâncias.

Resultados com um banco de dados parcialmente armazenado em cache

A saída do último comando em Executar o comparativo de mercado TPC-B do pgbench deve ser semelhante ao seguinte, em que --scale=50000:

pgbench: warning: scale option ignored, using count from pgbench_branches table (50000)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>

scaling factor: 50000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 68073405
latency average = 21.992 ms
latency stddev = 29.272 ms
tps = 17453.913041 (including connections establishing)
tps = 17460.373303 (excluding connections establishing)

Resumo dos resultados de desempenho de um comparativo de mercado TPC-B do pgbench

A tabela a seguir resume os resultados de desempenho de um benchmark pgbench TPC-B:

Cenário TPC-B SCALE_FACTOR TPS Uso da CPU (%)
Parcialmente armazenado em cache 50000 17.460 96%
Totalmente em cache 4000 21.750 94%

Executar um comparativo de mercado somente de inserção de índice

O comparativo de desempenho de inserção de índice é um cenário altamente concorrente e com muitas gravações que é personalizado nesta seção para mostrar os benefícios de desempenho do AlloyDB para a maioria dos aplicativos OLTP. Para executar esse benchmark, crie vários índices na tabela pgbench_history e execute operações INSERT repetidamente na tabela pgbench_history de várias conexões de cliente.

Os comparativos de inserção somente de índice medem o desempenho da inserção de dados em uma tabela de banco de dados, com foco específico no impacto dos índices na operação de gravação. Esse comparativo permite entender a rapidez com que novas linhas podem ser adicionadas a uma tabela com e sem índices, destacando a possível lentidão causada pela manutenção de índices durante as inserções.

O AlloyDB melhora o desempenho de gravação do PostgreSQL, o que também melhora as cargas de trabalho OLTP. Para melhorar o desempenho de cenários de OLTP com muitas gravações, o AlloyDB oferece inovações arquitetônicas, incluindo a camada de cache em camadas para ajudar nas leituras e uma tecnologia de mecanismo de armazenamento distribuída e altamente escalonável para gravações.

Configurar o AlloyDB e a máquina cliente

Para configurar a infraestrutura para executar um comparativo de mercado de inserção somente de índice, siga estas etapas:

  1. Crie um cluster e uma instância do AlloyDB, substituindo 16 vCPU and 128 GB RAM como o tipo de máquina.

  2. Provisione a máquina cliente, substituindo E2-standard-16 (minimum) como o tipo de máquina.

  3. Configure a máquina de comparativo de mercado.

  4. Faça uma limpeza de comparativo de mercado.

Executar a comparação de inserção somente de índice

  1. Conecte-se à máquina cliente usando o seguinte comando de exemplo:

    gcloud compute ssh --zone "<primary zone>" "<client machine name>" --project "<google-project>"

  2. Configure o ambiente executando o seguinte comando:

    export PGHOST=<private_ip>

  3. Crie um banco de dados pgbench usando o exemplo a seguir. Se o banco de dados já existir, exclua e recrie-o.

    psql -h $PGHOST -p 5432 -U postgres -c "DROP DATABASE IF EXISTS pgbench"
psql -h $PGHOST -p 5432 -U postgres -c "CREATE DATABASE pgbench"

  4. Inicialize e carregue o banco de dados pgbench para garantir que o conjunto de dados de comparativo seja criado e preenchido com dados realistas. Edite os parâmetros destacados e execute o seguinte comando:

    sudo nohup pgbench -i  --host=$PGHOST --user=postgres --scale=25000 pgbench > /tmp/pgbench-index-insert-only-init.out 2>&1
...

postgres=> create database pgbench;
CREATE DATABASE pgbench

  5. Verifique se a saída do comando anterior é semelhante a esta:

    dropping old tables...
creating tables...
generating data (client-side)...
100000 of 2500000000 tuples (0%) done (elapsed 0.03 s, remaining 636.43 s)
200000 of 2500000000 tuples (0%) done (elapsed 0.05 s, remaining 649.12 s)
.. .. ..
.. .. ..
2499900000 of 2500000000 tuples (99%) done (elapsed 3425.42 s, remaining 0.14 s)
2500000000 of 2500000000 tuples (100%) done (elapsed 3425.57 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 12851.19 s (drop tables 998.62 s, create tables 0.02 s, client-side generate 3460.33 s, vacuum 5299.93 s, primary keys 3092.29 s).

  6. Crie o script index-init.sql usando os seguintes comandos:

    cat > index-init.sql << EOF
CREATE INDEX tid ON pgbench_history(tid);
CREATE INDEX bid ON pgbench_history(bid);
CREATE INDEX aid ON pgbench_history(aid);
CREATE INDEX delta ON pgbench_history(delta);
CREATE INDEX mtime ON pgbench_history(mtime);
EOF

  7. Execute o script index-init.sql:

    psql -h $PGHOST -U postgres -d pgbench -f ./index-init.sql
Password for user postgres:
CREATE INDEX

  8. Opcional: validar o esquema do banco de dados e o carregamento inicial:

    psql -h $PGHOST -U postgres -d pgbench

pgbench=> \dt
           List of relations
Schema |       Name       | Type  |  Owner
--------+------------------+-------+----------
 public | pgbench_accounts | table | postgres
 public | pgbench_branches | table | postgres
 public | pgbench_history  | table | postgres
 public | pgbench_tellers  | table | postgres
(4 rows)

pgbench=> \di
                       List of relations
 Schema |         Name          | Type  |  Owner   |      Table
--------+-----------------------+-------+----------+------------------
 public | aid                   | index | postgres | pgbench_history
 public | bid                   | index | postgres | pgbench_history
 public | delta                 | index | postgres | pgbench_history
 public | mtime                 | index | postgres | pgbench_history
 public | pgbench_accounts_pkey | index | postgres | pgbench_accounts
 public | pgbench_branches_pkey | index | postgres | pgbench_branches
 public | pgbench_tellers_pkey  | index | postgres | pgbench_tellers
 public | tid                   | index | postgres | pgbench_history
(8 rows)

    Após o carregamento, o tamanho do banco de dados deve ser de cerca de 365 GB:

    pgbench=> \l+ pgbench
                         List of databases
Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size  | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+--------+------------+--------------------------------------------
...
 pgbench      | postgres         | UTF8     | C.UTF-8 | C.UTF-8 |                                       | 365 GB | pg_default |
...

  9. Crie o script index-inserts-only.sql usando os seguintes comandos:

    cat > index-inserts-only.sql << EOF
\set aid random(1, 1000000000)
\set bid random(1, 1000000000)
\set tid random(1, 1000000000)
\set delta random(-500000000, 500000000)
BEGIN;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
EOF

  10. Execute o comparativo de mercado do pgbench usando o seguinte comando:

    sudo nohup pgbench --host=$PGHOST --user=postgres --time=3900 --client=256 --jobs=256 --scale=25000 --progress=1 --file=./index-inserts-only.sql pgbench > /tmp/pgbench-index-insert-only-run.out 2>&1

Analisar os resultados da comparação

Verifique a saída do comando anterior no arquivo /tmp/pgbench-index-insert-only-run.out. Você vai notar aproximadamente 52 mil transações por segundo e uma taxa de utilização de CPU de aproximadamente 88% durante esse teste de comparação, conforme mostrado no exemplo de saída a seguir.

scaling factor: 25000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 201785196
latency average = 4.947 ms
latency stddev = 3.488 ms
tps = 51738.604613 (including connections establishing)
tps = 51742.459757 (excluding connections establishing)

Execute um comparativo de desempenho de "Selecionar somente" em uma instância de 64 vCPUs

O pgbench oferece suporte a um cenário integrado de seleção que executa repetidamente consultas SELECT de várias conexões de cliente em um banco de dados especificado. Esse comparativo é usado para medir o desempenho de leitura do banco de dados, sem introduzir a sobrecarga de operações de modificação de dados, como INSERT, UPDATE ou DELETE. Essas consultas SELECT são consultas de pesquisa de ponto, que são o tipo de consulta SELECT mais rápido e eficiente, porque envolvem o acesso a apenas uma única linha de dados diretamente das estruturas de índice.

A execução de um comparativo de mercado "Apenas seleção" ajuda você a:

  • Alcançar a capacidade máxima: como as pesquisas de ponto em um índice são a forma mais eficiente de consultas em um sistema de banco de dados, é possível medir a capacidade máxima possível que o AlloyDB pode alcançar.

  • Escalabilidade: selecione apenas os comparativos de mercado para testar a escalabilidade do AlloyDB de 2 vCPUs até a configuração máxima de vCPUs oferecida pelo AlloyDB.

Configurar o AlloyDB e a máquina cliente

Configure o AlloyDB e a máquina cliente em um tipo de máquina de 64 vCPU.

Executar a comparação do Select Only

  1. Conecte-se à máquina cliente usando o seguinte comando de exemplo:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. Configure o ambiente usando o seguinte comando:

    export PGHOST=<private_ip>

  3. Crie o banco de dados pgbench usando o exemplo a seguir:

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. Inicialize o banco de dados pgbench. O comando a seguir inicializa o banco de dados pgbench com aproximadamente 220 GB de dados realistas. Você usa --scale=15000 para o comparativo de mercado "Selecionar somente" totalmente armazenado em cache.

    Execute este comando:

    sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=15000 pgbench > /tmp/pgbench-select-only-init.out 2>&1

  5. Verifique se a saída do comando anterior é semelhante a esta:

    cat /tmp/pgbench-select-only-init.out
nohup: ignoring input
dropping old tables...
creating tables...
generating data (client-side)...
100000 of 1500000000 tuples (0%) done (elapsed 0.01 s, remaining 161.60 s)
200000 of 1500000000 tuples (0%) done (elapsed 0.03 s, remaining 224.35 s)
300000 of 1500000000 tuples (0%) done (elapsed 0.09 s, remaining 448.97 s)
.. .. ..
.. .. ..
1499900000 of 1500000000 tuples (99%) done (elapsed 1251.03 s, remaining 0.08 s)
1500000000 of 1500000000 tuples (100%) done (elapsed 1251.10 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 2204.62 s (drop tables 2.29 s, create tables 0.01 s, client-side generate 1271.82 s, vacuum 427.83 s, primary keys 502.66 s).

  6. Execute o pgbench. Essa etapa final de comparação de mercado leva mais de uma hora para ser concluída.

    sudo nohup pgbench --host=$PGHOST --user=postgres  --builtin=select-only --time=3900 --jobs=256 --client=256 --scale=15000 --protocol=simple --progress=1 pgbench > /tmp/pgbench-select-only-run.out  2>&1

  7. Depois que o comparativo for concluído, verifique os resultados finais no arquivo /tmp/pgbench-select-only-run.out.

Analisar os resultados da comparação

Você vai observar aproximadamente 467 mil transações por segundo e uma taxa de utilização da CPU de aproximadamente 95% durante este teste de comparação, conforme mostrado no exemplo de saída a seguir.

cat /tmp/pgbench-select-only-run.out
transaction type: <builtin: select only>
scaling factor: 15000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 1823506174
latency average = 0.547 ms
latency stddev = 0.267 ms
tps = 467563.144333 (including connections establishing)
tps = 467583.398400 (excluding connections establishing)

Resumo dos resultados do comparativo de mercado do AlloyDB

As tabelas a seguir resumem os resultados de comparação de mercado do AlloyDB com base nos testes realizados neste documento.

Resumo de desempenho do HammerDB TPC-C

Tipo de máquina do AlloyDB Cenário de carga de trabalho TPC-C NUM_WAREHOUSE NUM_USERS Novos pedidos por minuto (NOPM, na sigla em inglês) TPM cumulativo Convertido em TPS
16vCPU 30% em cache 3200 256 252.970 582.385 9.706
16vCPU 100% em cache 576 256 428.316 974.264 16.238
64vCPU 30% em cache 12800 1024 589.598 1.371.160 22.853
64vCPU 100% em cache 2304 1024 716.138 1.665.438 27.757

Resumo da performance do pgbench

Tipo de máquina do AlloyDB Cenário de carga de trabalho do pgbench Fator de escala TPS %de CPU
16vCPU TPC-B Like, totalmente em cache 4000 20.359 96%
16vCPU TPC-B Like, parcialmente em cache 50000 14.060 94%
16vCPU Somente inserções de índice 25.000 51.742 88%
64vCPU Capacidade máxima (somente seleção) 15000 467.583 95%

Executar a comparação de OLTP no Cloud SQL para PostgreSQL

É possível testar o desempenho equivalente do OLTP no PostgreSQL no Cloud SQL para PostgreSQL em um tipo de máquina de 16 vCPU para análise comparativa. Esta seção descreve como configurar um Cloud SQL para PostgreSQL (ou qualquer servidor PostgreSQL implantado na infraestrutura de sua escolha) que seja comparável à configuração do AlloyDB usada neste guia para comparar a performance do OLTP. Nesse cenário, inclui a escolha do SKU de 16 vCPU, a ativação da alta disponibilidade (HA) e a pré-configuração com armazenamento.

Antes de começar

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Install the Google Cloud CLI.

  5. To initialize the gcloud CLI, run the following command: 

    gcloud init

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Install the Google Cloud CLI.

  9. To initialize the gcloud CLI, run the following command: 

    gcloud init
  10. Verifique se você tem os papéis Administrador do Cloud SQL e Leitor do Compute na sua conta de usuário.

    Acessar a página IAM

    Saiba mais sobre papéis e permissões

Provisionar uma instância do Cloud SQL para PostgreSQL

  1. Crie uma instância do PostgreSQL, substituindo os seguintes valores:

    • Versão do banco de dados: PostgreSQL 14
    • Escolha uma configuração para começar: produção
    • Escolher a disponibilidade por região e zona: selecione us-central1 como a região.
    • Disponibilidade por zona: várias zonas (altamente disponível)
      • Zona principal: us-central1-c
      • Zona secundária: us-central-1-f
    • Tipo de máquina: máquina com 16 vCPUs e 104 GB de alta memória. Essa é a máquina mais próxima que o Cloud SQL para PostgreSQL oferece à instância correspondente do AlloyDB que você criou na seção de comparação de mercado do AlloyDB deste documento.
    • Capacidade de armazenamento: personalizada, 1.500 GB
      • Ativar aumento automático de armazenamento
    • Criptografia: Google-owned and Google-managed encryption key
    • Conexões: IP particular
      • Rede: default
      • IP público: ativado

  2. Clique em Criar instância.

  3. Depois que a instância do PostgreSQL for criada, anote o endereço IP particular. Você usa o IP como PGHOST para estabelecer conexões com o benchmark.

Provisionar a máquina cliente

  1. Provisione uma instância do Cloud SQL para PostgreSQL. Para executar o comparativo de mercado OLTP escolhido, você precisa de uma máquina cliente com capacidade de CPU significativa na mesma zona que a instância principal do Cloud SQL para PostgreSQL no Cloud SQL.

  2. Opcional: como alternativa à etapa anterior, use a mesma máquina cliente configurada para comparação de mercado do AlloyDB, desde que:

    • A máquina cliente está localizada na mesma zona que a nova instância principal do PostgreSQL (Cloud SQL para PostgreSQL).
    • A máquina cliente atende aos requisitos mínimos de CPU, RAM e tamanho do disco.

    Neste guia de comparação de mercado, você reutilizou as máquinas clientes quando elas estavam colocalizadas na mesma zona que a instância principal e quando eram grandes o suficiente para levar o servidor à capacidade total.

  3. Se você criou uma nova máquina cliente, configure a máquina de driver de comparação. Caso contrário, siga as instruções neste guia para o comparativo de mercado que você quer executar.

A seguir