Teste o desempenho de OLTP no AlloyDB para PostgreSQL

Este documento descreve como configurar o AlloyDB for PostgreSQL e um computador cliente para testar o desempenho do AlloyDB usando TPC-C, uma especificação de teste de referência OLTP. Este documento também descreve como executar cenários OLTP personalizados com utilização intensiva de leitura e escrita, como Index Insert Only e Select Only.

As instruções neste documento baseiam-se numa configuração específica do AlloyDB e do computador cliente. Use os valores fornecidos para cada passo nas instruções de testes de referência.

Capacidades de carga de trabalho do AlloyDB

O AlloyDB oferece fiabilidade, 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 funcionalidades que permitem um elevado desempenho para as suas cargas de trabalho transacionais (OLTP), analíticas (OLAP) e híbridas (HTAP):

  • Gestão de registos e transações
  • Gestão dinâmica de memória
  • Integração da inteligência artificial e da aprendizagem automática
  • Motor colunar incorporado
  • Uma cache de vários níveis
  • Armazenamento distribuído e escalável

Normalmente, os sistemas de bases de dados relacionais requerem que um administrador de base de dados otimize a base de dados para testes de referência, o que inclui a configuração das definições do registo de transações, o estabelecimento dos tamanhos certos do conjunto de buffers e a modificação de outros parâmetros ou caraterísticas e flags da base de dados. Estas definições variam consoante o tamanho e o tipo da instância.

O AlloyDB é pré-configurado com definições otimizadas para cada tipo de máquina. O AlloyDB não requer que ajuste as flags ao nível da base de dados para alcançar um elevado desempenho de OLTP. Em alternativa, o AlloyDB tem um elevado desempenho de OLTP incorporado.

Tipos de testes de referência suportados

Este documento mostra como executar testes de referência de OLTP com as seguintes ferramentas:

Drivers de testes de referência OLTP Exemplos de utilização
HammerDB 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 suporta a personalização de parâmetros de testes de referência, o que lhe permite ajustar o tamanho da base de dados, o número de armazéns e outras caraterísticas da carga de trabalho para simular diferentes cenários.

O HammerDB inclui uma implementação de referência TPC-C para avaliar o desempenho dos sistemas OLTP. A implementação do HammerDB TPC-C permite-lhe simular uma carga de trabalho semelhante à referência TPC-C, incluindo uma combinação de transações que imitam o comportamento de um ambiente de fornecedor grossista.
pgbench O pgbench é uma ferramenta de testes de referência fornecida com o PostgreSQL. O pgbench permite-lhe simular cargas de trabalho de transações, como inserir, atualizar, selecionar dados e medir o desempenho do sistema de base de dados em transações por segundo (TPS).

Quando usa o pgbench, pode personalizar o tamanho da base de dados, o número de clientes e a combinação de transações para emular a sua carga de trabalho de produção e obter estatísticas 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 uma referência do 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.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify 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.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. Ative as APIs Cloud necessárias para criar e estabelecer ligação ao AlloyDB para PostgreSQL.

    Ative as APIs

    1. No passo Confirmar projeto, clique em Seguinte para confirmar o nome do projeto ao qual vai fazer alterações.

    2. No passo Ativar APIs, clique em Ativar para ativar o seguinte:

      • API AlloyDB
      • API Compute Engine
      • Cloud Resource Manager API
      • API de rede de serviços

      A API Service Networking é necessária se planear configurar a conetividade de rede ao AlloyDB através de uma rede VPC que resida no mesmo Google Cloud projeto que o AlloyDB.

      A API Compute Engine e a API Cloud Resource Manager são necessárias se planear configurar a conetividade de rede ao AlloyDB através de uma rede VPC que reside num projeto Google Cloud diferente.

    7. Configure e aprovisione a base de dados e o computador cliente

    Comece o teste de referência criando um cluster e uma instância do AlloyDB. Salvo indicação em contrário, as informações neste documento baseiam-se numa instância do AlloyDB primária com 16 vCPUs e 128 GB de RAM.

    Crie um cluster e uma instância do AlloyDB

    1. Aceda à página Clusters.

      Aceda a Clusters

    2. Clique em Criar cluster.

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

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

    5. Selecione a rede predefinida.

    6. No campo Versão da base de dados, selecione PostgreSQL 16.

    7. Anote a localização da zona principal e o endereço IP privado. Não crie um conjunto de leitura.

    8. Clique em Criar cluster.

    Aprovisione a máquina cliente

    Para executar testes de referência de OLTP, precisa de um computador cliente com capacidade de processamento adequada. As ferramentas de testes de desempenho, como o HammerDB e o pgbench, são executadas de forma altamente paralela e consomem muita CPU. Uma máquina cliente não deve ser um fator limitativo quando executa um teste de referência OLTP.

    Salvo especificação em contrário, as instruções neste documento usam uma máquina E2-standard-32 com um disco de 128 GB como cliente para referências OLTP para acionar uma instância do AlloyDB numa máquina com 16 vCPUs e 128 GB de RAM. Tem de criar o computador cliente na mesma zona que a instância principal do AlloyDB.

    Para executar o teste de referência TPC-C numa instância principal do AlloyDB com 16 CPUs virtuais, siga estes passos para criar uma VM do Compute Engine e aprovisionar uma máquina cliente:

    1. Na Google Cloud consola, aceda à página Instâncias de VM.

      Aceder às instâncias de VM

    2. Selecione o projeto que contém a instância do AlloyDB à qual quer estabelecer ligação.
    3. Clique em Criar instância.
    4. Clique na secção Configuração da máquina.
    5. Introduza um nome para a instância.
    6. Configure a zona onde quer criar a instância. A zona tem de ser a mesma que a zona da instância principal do AlloyDB.
    7. Selecione um tipo de máquina de e2-standard-32.
    8. Mantenha os valores predefinidos na secção SO e armazenamento.
    9. Clique na secção Redes e defina Interfaces de rede para a rede VPC configurada para o acesso a serviços privados do AlloyDB.
      Se Interfaces de rede não estiver definido para a rede VPC configurada para o acesso a serviços privados, expanda-o e, em seguida, defina Rede para a rede VPC.
    10. Mantenha os valores predefinidos na secção Observability.
    11. Clique na secção Segurança.
    12. Em Identidade e acesso à API, defina os Âmbitos de acesso como Permitir acesso total a todas as APIs Google Cloud.
    13. Mantenha os valores predefinidos na secção Avançadas.
    14. Clique em Criar.
    15. Depois de criar a VM, estabeleça ligação à VM do Compute Engine que criou através do SSH.

    Configure a máquina de teste de desempenho do controlador

    Depois de instalar e configurar a base de dados e o computador cliente, configure o computador cliente em execução no Google Cloud, onde instala ferramentas de testes de referência, como o HammerDB e o pgbench.

    Para configurar a máquina de teste de referência do controlador, siga estes passos:

    1. Ligue-se ao computador cliente através do 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 seguinte comando para instalar um cliente PostgreSQL que inclua uma aplicação psql e, em seguida, certifique-se de que consegue estabelecer ligação.

        sudo apt-get update
sudo apt install postgresql-client

      2. Use o seguinte comando para garantir que o cliente funciona e que consegue estabelecer ligação ao AlloyDB. Use o endereço IP privado da sua instância principal do AlloyDB.

        psql -h PRIVATE_IP -U postgres

    3. Instale o controlador HammerDB-4.6 para o teste de desempenho 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 controlador pgbench para TPC-B e testes de referência OLTP diversos 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.

    Faça uma limpeza de referências

    Se planeia executar vários testes de referência sucessivamente, tem de fazer uma limpeza de testes de referência entre cada teste para garantir resultados de testes de referência precisos e fiáveis.

    Uma limpeza de testes de referência garante que os efeitos residuais de testes de referência anteriores não afetam as medições de desempenho do novo teste de referência. As limpezas de referências também ajudam a garantir a consistência e a repetibilidade dos resultados das referências, o que é essencial para fazer comparações significativas entre diferentes sistemas ou identificar áreas de otimização no hardware, software ou configuração.

    Siga estes passos para fazer uma limpeza de referências antes de executar outra referência:

    1. Elimine os dados de testes de referência anteriores ou a base de dados de testes de referência. Para eliminar a base de dados de testes de referência anterior, use o seguinte comando psql a partir do computador cliente:

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

      Para mais informações sobre a utilização da funcionalidade psql, consulte o artigo Estabeleça ligação a uma base de dados.

    2. Reinicie a instância do AlloyDB. Este passo limpa as caches ao nível da base de dados e do sistema operativo.

    Execute um teste de referência TPC-C

    O HammerDB é uma ferramenta de testes de referência que inclui uma implementação de testes de referência TPC-C para avaliar o desempenho dos sistemas OLTP. A implementação do TPC-C do HammerDB permite-lhe simular uma carga de trabalho semelhante à referência TPC-C, incluindo uma combinação de transações que imitam o comportamento de um ambiente de fornecedor grossista.

    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. Além disso, o HammerDB suporta a personalização dos parâmetros de teste de desempenho, o que permite aos utilizadores ajustar o tamanho da base de dados, o número de armazéns e outras caraterísticas da carga de trabalho para simular diferentes cenários.

    Cenários de avaliação do desempenho

    O desempenho dos testes de referência TPC-C é avaliado através dos seguintes métodos:

    • Modo parcialmente (~30%) em cache: neste modo, é gerada uma grande base de dados TPC-C, que só cabe parcialmente na cache do buffer. As transações neste modo nem sempre são servidas a partir da memória e incorrem em E/S para os subsistemas de armazenamento subjacentes. Este cenário é aplicável às necessidades de OLTP de muitos utilizadores.

    • Modo totalmente (100%) em cache: neste modo, a base de dados TPC-C cabe totalmente na cache do buffer. A instância do AlloyDB usa aproximadamente 90% dos 128 GB de RAM disponíveis, incluindo a cache de buffer.

      Uma vez que as transações TPC-C têm um desempenho mínimo de E/S, porque as leituras são servidas principalmente a partir da cache de buffer, neste modo, espera-se um TPM mais elevado em comparação com as execuções parcialmente em cache. Este cenário é aplicável às necessidades de OLTP dos utilizadores com necessidades de E/S muito baixas.

    Configure o computador cliente

    1. Configure a máquina do controlador de testes de referência.

    2. Se estiver a executar vários testes de referência sucessivamente, faça uma limpeza de referências.

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

      cd hammerdb/HammerDB-4.6

      Executa comandos a partir deste diretório para configurar o computador cliente.

    4. Crie o ficheiro setup.env com 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 ficheiro setup.env gerado substituindo todos os valores dos parâmetros realçados por valores dos parâmetros mais adequados à configuração do seu ambiente.

    6. Opcional: teste o modo de cache parcial (~30%) alterando NUM_WAREHOUSE para 3200 no ficheiro setup.env. Para mais informações, consulte o artigo Cenários de avaliação do desempenho.

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

    Carregue dados TPC-C na base de dados

    Um passo de carregamento refere-se ao processo de preenchimento da base de dados de testes de referência com dados iniciais antes de executar o teste de desempenho.

    Durante o passo de carregamento, a base de dados é preenchida 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 carregamento é criar uma carga de trabalho realista para o teste de desempenho e garantir que os resultados do teste são comparáveis em diferentes sistemas.

    Após a conclusão do passo de carregamento, a base de dados encontra-se num estado consistente com um conjunto definido de dados iniciais, pronta a ser usada para o teste de referência TPC-C.

    Para carregar a base de dados TPC-C, siga estes passos:

    1. Mude para o diretório base de referência através do seguinte comando:

      cd hammerdb/HammerDB-4.6

    2. Copie o seguinte conteúdo e, em seguida, cole-o 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 seguinte comando de carregamento e aguarde pela conclusão do comando.

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

    4. Valide o carregamento. Após a conclusão do script anterior, recomendamos que confirme se o carregamento da base de dados foi bem-sucedido. Para validar o tamanho da base 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)

    Numa configuração TPC-C em cache de 30% (com 3200 armazéns), o tamanho da base de dados tpcc deve ser de cerca de 300 GB.

    Na configuração do TPC-C com 100% de cache (com 576 armazéns), o tamanho da base de dados tpcc deve ser de cerca de 55 GB.

    Execute o teste de referência TPC-C

    Já pode executar o teste de desempenho TPC-C. A referência TPC-C é executada com a base de dados preenchida a partir do passo de carregamento. O teste de referência gera uma série de transações que simulam um ambiente empresarial típico, incluindo a introdução de encomendas, o processamento de pagamentos e a gestão de inventário. A carga de trabalho é medida em transações por minuto (TPM), que representa o número de transações comerciais concluídas que o sistema pode processar num minuto.

    O passo de execução foi concebido para testar o sistema de base de dados em condições realistas e fornecer uma forma padrão de medir o desempenho que pode comparar em diferentes sistemas de base de dados. Os fornecedores e os utilizadores usam frequentemente os resultados do teste de referência TPC-C para avaliar o desempenho de diferentes sistemas de bases de dados e configurações de hardware.

    Para executar o teste de referência TPC-C, siga estes passos:

    1. Mudar para o diretório base de referência:

      cd hammerdb/HammerDB-4.6

    2. Copie o seguinte conteúdo e, em seguida, cole-o 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 através dos seguintes comandos:

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

    4. Aguarde que o script run-tpcc.sh termine. O script demora aproximadamente 1 hora e 10 minutos a concluir. Após a conclusão do script, pode analisar os resultados.

    Analise os resultados de testes de referência

    Nos testes de referência TPC-C, as novas encomendas por minuto (NOPM) e as transações por minuto (TPM) são métricas de desempenho usadas para medir o desempenho de um sistema de base de dados.

    • NOPM: mede o número de transações de novas encomendas que o sistema consegue processar num minuto. A transação de nova encomenda é uma das transações mais importantes na referência TPC-C e envolve a criação de uma nova encomenda para um cliente.

    • TPM: mede o número total de transações comerciais concluídas que o sistema consegue processar num minuto. As transações incluem transações de novas encomendas, bem como outros tipos de transações definidos na referência TPC-C, como pagamento, entrega e estado da encomenda.

      O TPM é a principal métrica de desempenho para o teste de referência TPC-C porque fornece uma medida geral da capacidade do sistema de processar uma carga de trabalho realista. O NOPM pode ser uma métrica útil para sistemas focados no processamento de novas encomendas, como sistemas de comércio eletrónico ou retalho.

    Veja os resultados com uma base de dados TPC-C em cache de 30% numa máquina com 16 vCPUs

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

    grep NOPM results/run-tpcc.out

    Segue-se o resultado esperado:

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

    Com 30% da base de dados TPC-C em cache numa máquina com 16 vCPUs (com NUM_WAREHOUSE=3200 e NUM_USERS=256), observa 252 970 tpm-C (New Order Per Minute) a partir de um TPM cumulativo do AlloyDB de 582 385.

    Veja os resultados com uma base de dados TPC-C 100% em cache numa máquina com 16 vCPUs

    Numa base de dados TPC-C 100% em cache numa máquina com 16 vCPUs (com NUM_WAREHOUSE=576e NUM_USERS=256), observa 428 316 tpm-C (New Order Per Minute) de um total de 974 264 TPM do AlloyDB.

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

    grep NOPM results/tpcc-run.out

    Segue-se o resultado esperado:

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

    Resumo dos resultados de desempenho na máquina com 16 vCPUs

    A tabela seguinte resume os resultados de desempenho de referência para uma máquina com 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

    Observe as métricas de desempenho da base de dados

    Para compreender melhor o comportamento do sistema de base de dados, use as ferramentas de monitorização do AlloyDB para observar métricas importantes do sistema, como a utilização da CPU, a utilização da memória e as transações por segundo. Para mais informações, consulte o artigo Monitorize o desempenho da instância.

    Por exemplo, após executar este teste de referência, pode observar na página Vista geral do AlloyDB na consola que a utilização média da CPU para a execução do TPC-C com 100% de cache é quase de 90%. Google Cloud

    Execute um teste de referência TPC-C numa instância do AlloyDB com 64 vCPUs

    Para executar um teste de benchmark TPC-C numa instância do AlloyDB com 64 vCPUs, siga os mesmos passos de configuração que em Executar um teste de benchmark TPC-C, mas use tipos de máquinas diferentes.

    Configure o AlloyDB e o computador cliente

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

    2. Aprovisione a máquina cliente, substituindo n2-standard-64 pelo tipo de máquina.

    3. Configure a máquina do controlador de testes de referência.

    Execute o teste de referência

    1. Se estiver a executar vários testes de referência sucessivamente, faça uma limpeza de referências.

    2. Configure o computador cliente, substituindo os seguintes valores:

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

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

    4. Execute o teste de referência TPC-C.

    Analise os resultados de testes de referência

    A tabela seguinte resume os resultados de desempenho de referência numa máquina com 64 vCPUs:

    Modo de referência 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

    Execute uma referência TPC-B do pgbench

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

    • Depósitos
    • Levantamentos
    • Consultas de saldo

    O teste de referência mede o desempenho do sistema de base de dados simulando uma combinação destas transações e medindo o número de transações por segundo que o sistema consegue processar.

    O modo TPC-B no pgbench gera uma base de dados sintética e simula uma combinação de transações semelhante à carga de trabalho TPC-B, mas não é oficialmente certificada pela organização TPC. Por conseguinte, embora o modo TPC-B no pgbench forneça uma aproximação útil do desempenho do TPC-B, não o use para reivindicar a conformidade com as normas do TPC-B.

    Cenários para medir o desempenho

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

    Cenário de base de dados parcialmente em cache

    Neste cenário, configura e inicializa uma base de dados grande (com aproximadamente 650 GB) através do --scale= 50000. Ter uma base de dados grande que não cabe na memória e causa uma E/S de disco significativa oferece uma representação realista de muitas cargas de trabalho de produção.

    Uma base de dados grande que cause uma E/S de disco significativa pode realçar a importância do design da base de dados e da otimização de consultas. Uma base de dados grande também pode expor problemas de desempenho relacionados com a E/S do disco, como acesso lento ao disco ou consultas ineficientes, que podem não ser evidentes numa base de dados pequena ou totalmente residente na memória.

    Cenário de base de dados totalmente em cache

    Neste cenário, configura e inicializa uma base de dados de aproximadamente 60 GB usando --scale=4000 para que resida no conjunto de buffers. A realização de testes de referência numa base de dados residente na memória é importante porque permite avaliar o desempenho máximo do sistema de base de dados num ambiente controlado.

    Uma base de dados residente na memória armazena todos os dados no conjunto de buffers do PostgreSQL, o que elimina o gargalo de E/S que pode ocorrer quando acede a dados do disco. Este modo pode ajudar a identificar gargalos de desempenho que não estão relacionados com a E/S, como a utilização da CPU ou problemas de bloqueio, que podem não ser evidentes quando compara o desempenho de uma base de dados que depende da E/S de disco.

    Configure o servidor de base de dados e o computador cliente

    Para configurar a infraestrutura para executar uma referência TPC-B do pgbench, siga estes passos:

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

    2. Aprovisione a máquina cliente, substituindo E2-standard-16 (minimum) pelo tipo de máquina.

    3. Configure a máquina do controlador de testes de referência.

    4. Faça uma limpeza de referências.

    Execute o teste de referência TPC-B do pgbench

    1. Estabeleça ligação à máquina cliente através do seguinte comando da Google Cloud CLI:

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

    2. Crie o ficheiro 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 ficheiro setup.env gerado e substitua o seguinte valor do parâmetro por valores adequados à configuração do seu ambiente.

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

      Use a tabela seguinte para escolher os valores <scale_factor> e <num_clients>. Estes valores têm de ser dimensionados com o tipo de máquina e o tamanho da base de dados (totalmente em cache ou parcialmente em cache). Os exemplos neste guia usam valores SCALE_FACTOR e NUM_CLIENT correspondentes ao n2-highmem-16 tipo de máquina.

      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 25000 128
      n2-highmem-16 4000 384 50000 256
      n2-highmem-32 8000 768 100000 512
      n2-highmem-64 16000 1536 200000 1024

    4. Crie uma base de dados pgbench.

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

    5. Inicialize e carregue a base de dados pgbench executando os seguintes comandos. Este passo garante que o conjunto de dados de testes de referência é criado e preenchido com dados realistas, o que lhe permite simular com precisão uma carga de trabalho TPC-B na base 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 carregamento da base de dados parcialmente em cache demora aproximadamente 6 horas.
      • O carregamento da base de dados totalmente em cache demora aproximadamente 45 minutos.

    6. Opcional: faça uma verificação da precisão do carregamento certificando-se de que o conteúdo do ficheiro é semelhante ao seguinte:/tmp/pgbench-tpcb-partially-cached-db-init.out

      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 do carregamento, execute o seguinte comando do PostgreSQL que mede o tamanho de todas as tabelas pgbench:

      1. Ligue-se à base 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 o resultado do comando anterior com o resultado que obteve para a execução da base de dados parcialmente 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 seguintes comandos para simular uma carga de trabalho de um sistema de contabilidade financeira executando uma série de transações que envolvem depósitos, transferências e pagamentos, o que lhe permite medir o desempenho da base 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

    Analise os resultados de testes de referência

    Verifique a saída do comando anterior no ficheiro ~/results/alloydb/pgbench/pgbench.run.out. O número de TPS deve ser próximo dos números apresentados nos cenários de base de dados totalmente em cache e de base de dados parcialmente em cache.

    Resultados com uma base de dados totalmente em cache

    O resultado do último comando em Execute o teste de referência TPC-B do pgbench deve ser semelhante ao seguinte, onde --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 compreender melhor o comportamento do sistema de base de dados, pode monitorizar métricas do sistema, como a utilização da CPU, a utilização da memória e as transações por segundo através da Google Cloud consola. Para mais informações, consulte o artigo Monitorize instâncias.

    Resultados com uma base de dados parcialmente em cache

    O resultado do último comando em Execute o teste de referência TPC-B do pgbench deve ser semelhante ao seguinte, onde --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 para uma referência TPC-B do pgbench

    A tabela seguinte resume os resultados de desempenho para uma referência TPC-B do pgbench:

    Cenário TPC-B SCALE_FACTOR TPS Utilização da CPU (%)
    Parcialmente em cache 50000 17 460 96%
    Totalmente em cache 4000 21 750 94%

    Execute um teste de referência de inserção apenas de índice

    O teste de referência Index Insert Only é um cenário de escrita intensiva e altamente concorrente que é personalizado nesta secção para mostrar as vantagens de desempenho do AlloyDB para a maioria das aplicações OLTP. Para executar este teste de referência, cria vários índices na tabela pgbench_history e, em seguida, executa repetidamente operações INSERT na tabela pgbench_history a partir de várias ligações de cliente.

    Os testes de referência de inserção apenas de índice medem o desempenho da inserção de dados numa tabela da base de dados, focando-se especificamente no impacto dos índices na operação de escrita. Este teste de referência permitiu-lhe compreender a rapidez com que é possível adicionar novas linhas a uma tabela com e sem índices, realçando a potencial desaceleração causada pela manutenção de índices durante as inserções.

    O AlloyDB melhora o desempenho de escrita do PostgreSQL, o que também melhora as cargas de trabalho OLTP. Para melhorar o desempenho dos cenários OLTP com escrita intensiva, o AlloyDB oferece inovações arquitetónicas, incluindo uma camada de cache hierarquizada para ajudar com as leituras e uma tecnologia de motor de armazenamento distribuída e altamente escalável para escritas.

    Configure o AlloyDB e o computador cliente

    Para configurar a infraestrutura para executar um teste de referência de inserção apenas de índice, siga estes passos:

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

    2. Aprovisione a máquina cliente, substituindo E2-standard-16 (minimum) pelo tipo de máquina.

    3. Configure a máquina do controlador de testes de referência.

    4. Faça uma limpeza de referências.

    Execute o teste de referência de inserção de índice apenas

    1. Faça a ligação à máquina cliente através do 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 uma base de dados pgbench usando o exemplo seguinte. Se a base de dados já existir, elimine-a e recrie-a.

      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 a base de dados pgbench para garantir que o conjunto de dados de testes de referência é criado e preenchido com dados realistas. Edite os parâmetros realçados e, de seguida, 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 o resultado do comando anterior é semelhante ao seguinte:

      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 com 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: valide o esquema da base 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 da base de dados deverá 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 com 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 teste de referência pgbench com 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

    Analise os resultados de testes de referência

    Verifique a saída do comando anterior no ficheiro /tmp/pgbench-index-insert-only-run.out. Deve ver aproximadamente 52 mil transações por segundo e uma taxa de utilização da CPU de ~88% durante este teste de referência, conforme mostrado no seguinte exemplo de resultado.

    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 teste de benchmark Select Only numa instância com 64 vCPUs

    O pgbench suporta um cenário incorporado apenas de seleção que executa repetidamente consultas SELECT de várias ligações de clientes numa base de dados especificada. Esta referência é usada para medir o desempenho de leitura da base de dados, sem introduzir a sobrecarga de operações de modificação de dados, como INSERT, UPDATE ou DELETE. Estas consultas SELECT são consultas de pesquisa pontual que são o tipo de consultas select mais rápido e eficiente, uma vez que envolvem o acesso apenas a uma única linha de dados diretamente das estruturas de índice.

    A execução de um teste de referência de seleção única ajuda a alcançar o seguinte:

    • Alcançar o débito máximo: uma vez que as pesquisas pontuais num índice são a forma mais eficiente de consultas num sistema de base de dados, pode medir o débito máximo possível que o AlloyDB pode alcançar.

    • Escalabilidade: a seleção de apenas referências ajuda a testar a escalabilidade do AlloyDB de 2 vCPUs para a configuração máxima de vCPUs oferecida pelo AlloyDB.

    Configure o AlloyDB e o computador cliente

    Configure o AlloyDB e a máquina cliente num tipo de máquina de 64 vCPUs.

    Execute o teste de referência Select Only

    1. Faça a ligação à máquina cliente através do seguinte comando de exemplo:

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

    2. Configure o ambiente com o seguinte comando:

      export PGHOST=<private_ip>

    3. Crie a base de dados pgbench com o seguinte exemplo:

      psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

    4. Inicialize a base de dados pgbench. O comando seguinte inicializa a base de dados pgbench com aproximadamente 220 GB de dados realistas. Usa --scale=15000 para a referência de apenas seleção totalmente em cache.

      Execute o seguinte comando:

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

    5. Verifique se o resultado do comando anterior é semelhante ao seguinte:

      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. Este passo de testes de referência final demora mais de uma hora a ser concluído.

      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. Após a conclusão do teste de referência, verifique o ficheiro /tmp/pgbench-select-only-run.out para ver os resultados finais.

    Analise os resultados de testes de referência

    Deve observar aproximadamente 467 mil transações por segundo e uma taxa de utilização da CPU de ~95% durante este teste de referência, conforme mostrado no seguinte exemplo de resultado.

    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 de testes de referência do AlloyDB

    As tabelas seguintes resumem os resultados de testes de referência do AlloyDB com base nos testes realizados neste documento.

    Resumo do desempenho do HammerDB TPC-C

    Tipo de máquina do AlloyDB Cenário de carga de trabalho TPC-C NUM_WAREHOUSE NUM_USERS Novas encomendas por minuto (NOPM) TPM cumulativo Convertido em TPS
    16vCPU 30% em cache 3200 256 252 970 582 385 9706
    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 do desempenho do pgbench

    Tipo de máquina do AlloyDB Cenário de carga de trabalho pgbench Fator de escala TPS CPU %
    16vCPU TPC-B Like, Fully Cached 4000 20 359 96%
    16vCPU TPC-B Like, parcialmente em cache 50000 14 060 94%
    16vCPU Apenas inserções de índice 25000 51 742 88%
    64vCPU Débito máximo (apenas seleção) 15000 467 583 95%

    Execute testes de referência de OLTP no Cloud SQL para PostgreSQL

    Pode testar o desempenho de OLTP equivalente no PostgreSQL no Cloud SQL for PostgreSQL num tipo de máquina de 16 vCPUs para análise comparativa. Esta secção descreve como configurar um Cloud SQL for PostgreSQL (ou qualquer servidor PostgreSQL implementado na infraestrutura à sua escolha) comparável à configuração do AlloyDB usada neste guia para testar o desempenho de OLTP. Neste cenário, inclui a escolha de uma SKU de 16 vCPUs, a ativação da elevada 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.

      Roles required to select or create a project

      • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
      • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

      Go to project selector

    3. Verify that billing is enabled for your Google Cloud project.

    4. Install the Google Cloud CLI.

    5. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

    6. Para inicializar a CLI gcloud, execute o seguinte comando: 

      gcloud init

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

      Roles required to select or create a project

      • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
      • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

      Go to project selector

    8. Verify that billing is enabled for your Google Cloud project.

    9. Install the Google Cloud CLI.

    10. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

    11. Para inicializar a CLI gcloud, execute o seguinte comando: 

      gcloud init
    12. Certifique-se de que tem as funções de administrador do Cloud SQL e leitor do Compute na sua conta de utilizador.

      Aceda à página IAM

      Saiba mais acerca das funções e autorizações.

      13. Aprovisione uma instância do Cloud SQL para PostgreSQL

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

        • Versão da base de dados: PostgreSQL 14
        • Escolha uma configuração para começar: produção
        • Escolha a região e a disponibilidade por zona: selecione us-central1 como região.
        • Disponibilidade zonal: várias zonas (altamente disponível)
          • Zona principal: us-central1-c
          • Zona secundária: us-central-1-f
        • Tipo de máquina: memória elevada, 16 vCPU, máquina de 104 GB. Esta é a máquina mais próxima que o Cloud SQL for PostgreSQL oferece à instância do AlloyDB correspondente que criou na secção de testes de benchmark do AlloyDB deste documento.
        • Capacidade de armazenamento: personalizado, 1500 GB
          • Ative os aumentos automáticos de armazenamento
        • Encriptação: Google-owned and Google-managed encryption key
        • Ligações: IP privado
          • Rede: default
          • IP público: ativado

      2. Clique em Criar instância.

      3. Depois de criar a instância do PostgreSQL, tome nota do endereço IP privado. Usa o IP como PGHOST para estabelecer ligações com a referência.

      Aprovisione a máquina cliente

      1. Aprovisione uma instância do Cloud SQL para PostgreSQL. Para executar o teste de referência OLTP da sua escolha, precisa de uma máquina cliente com uma potência de CPU significativa na mesma zona que a instância principal do Cloud SQL para PostgreSQL no Cloud SQL.

      2. Opcional: em alternativa ao passo anterior, pode usar o mesmo computador cliente que configurou para a análise comparativa do AlloyDB, desde que se verifique o seguinte:

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

        Neste guia de testes de referência, reutilizou as máquinas cliente quando estavam localizadas na mesma zona que a instância principal e quando eram suficientemente grandes para levar o servidor à sua capacidade total.

      3. Se criou um novo computador cliente, configure o computador do controlador de testes de referência. Caso contrário, siga as instruções neste guia para a referência que tem interesse em executar.

      O que se segue?