Comparação de desempenho OLTP no AlloyDB para PostgreSQL

Neste documento, descrevemos 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 OLTP. Este documento também descreve como executar cenários de OLTP personalizados com leitura e gravação intensivas, como Index Insert Only e Select Only.

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 das instruções de comparativo de mercado.

Recursos de carga de trabalho do AlloyDB

O AlloyDB oferece confiabilidade, escalonabilidade 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 suas cargas de trabalho transacionais (OLTP), analíticas (OLAP) e híbridas (HTAP):

• Gerenciamento de registros e transações
• Gerenciamento dinâmico de memória
• 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 comparativos de mercado, o que inclui configurar as configurações de registro de transações, estabelecer os tamanhos certos de pool de buffers e modificar outros parâmetros, flags 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 alcançar alto desempenho de OLTP. Em vez disso, o AlloyDB já tem alto desempenho de OLTP integrado.

Observação: a precisão dos resultados pode variar dependendo de vários fatores, incluindo o tipo de instância do AlloyDB, o tipo de máquina cliente que executa o comparativo, a região, a zona e a largura de banda da rede no momento do teste.

Tipos de comparativos de mercado compatíveis

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

Drivers de comparativo de mercado de OLTP	Use cases
HammerDB	O HammerDB mede a performance do sistema em termos de transações por minuto (TPM) e gera relatórios que incluem estatísticas detalhadas e métricas de performance. O HammerDB é compatível com a personalização de parâmetros de comparativo de mercado, o que permite ajustar o tamanho do banco de dados, o número de armazéns e outras características da carga de trabalho para simular diferentes cenários. O HammerDB 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.
pgbench	O pgbench é uma ferramenta de comparativo de mercado fornecida com o PostgreSQL. Ele permite simular cargas de trabalho de transação, como inserção, atualização, seleção de dados e medição do desempenho do sistema de banco de dados em transações por segundo (TPS). 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 sua 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 pgbench TPC-B é semelhante a um comparativo de mercado TPC-B.

Antes de começar

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.

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

   Ative 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 com o AlloyDB usando uma rede VPC que reside no mesmo projeto Google Cloud do AlloyDB.

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

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 se baseiam em uma instância principal do AlloyDB com 16 vCPUs e 128 GB de RAM.

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 16.

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

   Observação: este exercício de comparativo de mercado é realizado sem pools de leitura. A instância precisa ser de alta disponibilidade e várias zonas.

8. Clique em Criar cluster.

Provisionar a máquina cliente

Para executar comparativos de mercado de OLTP, você precisa de uma máquina cliente com capacidade de processamento adequada. Ferramentas de comparativo 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 ao executar um comparativo de mercado de OLTP.

A menos que especificado de outra forma, as instruções neste documento usam uma máquina E2-standard-32 com um disco de 128 GB como cliente para comparativos de mercado de OLTP, impulsionando 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.

Importante: para executar o comparativo de mercado de OLTP descrito neste documento, é necessário provisionar o cliente Linux Debian na mesma região, zona e VPC da instância principal do AlloyDB. As ferramentas de comparativo de mercado acessam a instância do AlloyDB por IP particular.

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 VM.

   Acessar instâncias de VM

2. Selecione o projeto que contém a instância do AlloyDB a que 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 como a rede VPC configurada para acesso a serviços particulares ao AlloyDB.
   Se Interfaces de rede não estiver definido como a rede VPC configurada para o acesso a serviços particulares, expanda e defina Rede 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 comparativo de mercado

Depois de instalar e configurar o banco de dados e a máquina cliente, configure a máquina cliente executada em Google Cloud, onde você instala ferramentas de comparativo de mercado, 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 verifique se é possível se conectar.

      sudo apt-get update
      sudo apt install postgresql-client

   2. Use o comando a seguir para garantir que o cliente funcione e que você consiga se conectar ao AlloyDB. Use o endereço IP privado da instância primária 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 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, isso significa que o pgbench está instalado.

Fazer uma limpeza de comparativo de mercado

Se você planeja executar várias comparações sucessivas, faça uma limpeza entre elas para garantir resultados precisos e confiáveis.

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

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

1. Exclua os dados ou o banco de dados de comparativo de mercado anteriores. Para descartar 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. Essa 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 a performance 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 a performance do sistema em termos de transações por minuto (TPM) e gera relatórios que incluem estatísticas detalhadas e métricas de performance. Além disso, o HammerDB permite personalizar os parâmetros de comparativo de mercado, ajustando o tamanho do banco de dados, o número de armazéns e outras características da carga de trabalho para simular diferentes cenários.

Situações 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 só pode caber parcialmente no cache de buffer. As transações nesse modo nem sempre são veiculadas da 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 totalmente (100%) em cache: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 feitas principalmente do cache de buffer), nesse modo, é esperado um TPM mais alto 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 driver de comparativo de mercado.

2. Se você estiver executando várias comparações sucessivas, faça uma limpeza de comparativo.

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

   cd hammerdb/HammerDB-4.6

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

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

   Observação: se você estiver usando o pool de conexões gerenciadas, mude o número da porta de 5432 para 6432. Aplique em todos os exemplos desta página.

   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

   Observação: o número de usuários (ou clientes) está definido como 256. Esse número de usuários é ajustado para oferecer a melhor capacidade de processamento com latência aceitável nas configurações parcialmente e totalmente armazenadas em cache.

5. Edite o arquivo setup.env gerado substituindo todos os valores de parâmetro destacados pelos que melhor se adequam à configuração do seu ambiente.

6. Opcional: teste o modo parcialmente (~30%) armazenado em cache 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 totalmente (100%) armazenado em cache mudando NUM_WAREHOUSE para 576 no setup.env file. Para mais informações, consulte Cenários de avaliação de desempenho.

Carregar dados do TPC-C no banco de dados

Uma etapa de carga se refere ao processo de preencher o banco de dados de comparativo 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. A finalidade da etapa de carga é criar uma carga de trabalho realista para o teste de performance e garantir que os resultados sejam comparáveis em diferentes sistemas.

Depois que a etapa de carregamento for concluída, o banco de dados estará em um estado consistente com um conjunto definido de dados iniciais, pronto para ser usado no teste de comparativo de mercado TPC-C.

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

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

   cd hammerdb/HammerDB-4.6

2. Copie o conteúdo a seguir e cole 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 carga 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 (3.200 armazéns), o tamanho do banco de dados tpcc será de aproximadamente 300 GB.

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

Executar o comparativo de mercado TPC-C

Agora você já pode executar o teste de performance 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), 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 testar o sistema de banco de dados em condições realistas e fornecer uma maneira padrão de medir o desempenho que pode ser comparado em diferentes sistemas de banco de dados. Os fornecedores e usuários costumam usar os resultados do comparativo de mercado TPC-C para avaliar a performance de diferentes sistemas de banco de dados e configurações de hardware.

Observação: o script a seguir executa o comparativo de mercado TPC-C por cerca de uma hora após aproximadamente 10 minutos de preparação.

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

1. Mude para o diretório inicial do comparativo de mercado:

   cd hammerdb/HammerDB-4.6

2. Copie o conteúdo a seguir e cole 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 TPC-C, os novos pedidos por minuto (NOPM) e as transações por minuto (TPM) são métricas de performance usadas para medir o desempenho de um sistema de banco de dados.

• NOPM:mede o número de transações de novos pedidos que o sistema pode processar em um minuto. A transação de novo pedido é uma das mais importantes no comparativo 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 novos pedidos e outros tipos definidos no comparativo de mercado TPC-C, como pagamento, entrega e status do pedido.

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

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

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

grep NOPM results/run-tpcc.out

Esta é a resposta esperada:

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 (New Order Per Minute) de um TPM cumulativo de 582.385 do AlloyDB.

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

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

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

grep NOPM results/tpcc-run.out

Esta é a resposta esperada:

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

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

A tabela a seguir resume os resultados de desempenho do 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 métricas de desempenho do banco de dados

Para entender melhor o comportamento do seu 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 o desempenho da instância.

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

Executar um benchmark TPC-C em uma instância do AlloyDB de 64 vCPUs

Para executar um comparativo de mercado TPC-C em uma instância do AlloyDB de 64 vCPUs, siga as mesmas etapas de configuração em Executar um comparativo de mercado TPC-C, mas use tipos de máquinas 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 n2-standard-64 como o tipo de máquina.

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

Executar a comparação

1. Se você estiver executando várias comparações sucessivas, faça uma limpeza de comparativo.

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

   • Defina PGHOST como o IP particular da nova instância do AlloyDB de 64 vCPUs.
   • Para o cenário de 30% do TPC-C em cache, defina NUM_WAREHOUSE=12800 e NUM_USERS=1024.
   • Para um cenário de TPC-C 100% armazenado em 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. Execute o comparativo de mercado TPC-C.

Analisar os resultados da comparação

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

Modo 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 TPC-B do pgbench

O 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 em contas de clientes. A carga de trabalho consiste nos seguintes tipos de transações:

• Depósitos
• Retiradas
• Consultas de saldo

O comparativo 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 semelhante à carga de trabalho TPC-B, mas não é oficialmente certificado 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 reivindicar a conformidade com os padrões do 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 diferente nesses modos é o valor de 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 significativa 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 buffers. É importante fazer comparativos de mercado com um banco de dados residente na memória porque isso permite avaliar o desempenho máximo do sistema em um ambiente controlado.

Um banco de dados residente na 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 a E/S, como uso da CPU ou problemas de bloqueio, que podem não ser aparentes ao fazer um comparativo de um banco de dados que depende de 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 TPC-B do pgbench, 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 driver de comparativo de mercado.

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

Executar o comparativo de mercado TPC-B do pgbench

Importante: recomendamos que você execute o comparativo por mais tempo porque a taxa de transferência é menor nos primeiros segundos, e leva tempo para atingir um estado estável.

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

   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 seu ambiente.

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

   Use a tabela a seguir para escolher os valores de <scale_factor> e <num_clients>. Esses valores precisam ser dimensionados com o tipo de máquina e o tamanho do banco de dados (totalmente 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	8000	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. Inicialize e carregue o banco de dados pgbench executando os seguintes comandos. Essa etapa garante que o conjunto de dados de comparativo 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 6 horas para carregar.
   • O banco de dados totalmente armazenado em cache leva aproximadamente 45 minutos para ser carregado.

6. Opcional: faça uma verificação de acurácia do carregamento para garantir 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 do seu carregamento, execute o seguinte comando do PostgreSQL que mede o tamanho de todas as tabelas 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 obtida para a execução do banco de dados parcialmente armazenado 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 a seguir para simular uma carga de trabalho de um sistema de contabilidade financeira. Isso é feito 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

Confira a saída do comando anterior no arquivo ~/results/alloydb/pgbench/pgbench.run.out. O número de TPS deve ser próximo aos números mostrados nos cenários de banco de dados totalmente e parcialmente armazenados em cache.

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 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, uso 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 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 performance para um comparativo de mercado TPC-B do pgbench

A tabela a seguir resume os resultados de desempenho de um comparativo de mercado TPC-B do pgbench:

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

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

O benchmark "Index Insert Only" é um cenário altamente simultâneo e com uso intenso de gravação, personalizado nesta seção para mostrar os benefícios de performance do AlloyDB para a maioria dos aplicativos OLTP. Para executar esse comparativo de mercado, crie vários índices na tabela pgbench_history e execute repetidamente operações INSERT na tabela pgbench_history de várias conexões de cliente.

Os comparativos de Insert Only Index 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. Com esse comparativo, você entende 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 de OLTP. Para melhorar a performance de cenários de OLTP com muitas gravações, o AlloyDB oferece inovações de arquitetura, incluindo uma camada de cache em níveis 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 e executar um comparativo de Insert Only Index, 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 driver de comparativo de mercado.

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

Executar o comparativo de Insert Only do Index

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>
   

   Importante: execute todos os comandos restantes neste procedimento no mesmo terminal do cliente. Em seguida, basta exportar a variável de ambiente PGHOST uma vez e atribuí-la ao IP privado da instância do AlloyDB. Se você conectar vários terminais à máquina cliente, exporte a seguinte variável de ambiente em todos os terminais.

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

   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 de mercado 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: valide 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 aproximadamente 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 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 da CPU de ~88% durante esse teste de comparativo de mercado, 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)

Executar um comparativo de mercado "Select Only" em uma instância de 64 vCPUs

O pgbench oferece suporte a um cenário integrado somente de seleção que executa repetidamente consultas SELECT de várias conexões de clientes 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 de pesquisa pontual, o tipo mais rápido e eficiente de consultas SELECT, porque envolvem o acesso a apenas uma linha de dados diretamente das estruturas de índice.

Executar um comparativo de mercado "Selecionar somente" ajuda você a fazer o seguinte:

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

• Escalonabilidade: selecione apenas comparativos de mercado que ajudam a testar a escalonabilidade 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 vCPUs.

Executar o comparativo de mercado "Selecionar somente"

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>
   

   Importante: execute todos os comandos restantes neste procedimento no mesmo terminal do cliente. Em seguida, basta exportar a variável de ambiente PGHOST uma vez e atribuí-la ao IP privado da instância do AlloyDB. Se você conectar vários terminais à máquina cliente, exporte a seguinte variável de ambiente em todos os terminais.

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 pgbench. Essa etapa final de comparativo 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, confira o arquivo /tmp/pgbench-select-only-run.out para ver os resultados finais.

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 ~95% durante esse teste de comparativo de mercado, 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 do comparativo de mercado do AlloyDB com base nos testes realizados neste documento.

Resumo da performance 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)	TPM cumulativo	Convertido para 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	%da CPU
16vCPU	TPC-B Like, Fully Cached	4000	20.359	96%
16vCPU	TPC-B Like, Partially Cached	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 comparativos de mercado de OLTP no Cloud SQL para PostgreSQL

É possível testar o desempenho equivalente de OLTP no PostgreSQL no Cloud SQL para PostgreSQL em um tipo de máquina de 16 vCPUs para análise comparativa. Nesta seção, descrevemos como configurar um Cloud SQL para PostgreSQL (ou qualquer servidor PostgreSQL implantado na infraestrutura de sua escolha) comparável à configuração do AlloyDB usada neste guia para fazer o comparativo de performance de OLTP. Nesse cenário, você escolhe um SKU de 16 vCPUs, ativa a alta disponibilidade (HA) e faz uma pré-configuração com armazenamento.

Antes de começar

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.

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

Ao usar um provedor de identidade (IdP) externo, primeiro faça login na gcloud CLI com sua identidade federada.

Para inicializar a gcloud CLI, execute o seguinte comando:

gcloud init

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

Ao usar um provedor de identidade (IdP) externo, primeiro faça login na gcloud CLI com sua identidade federada.

Para inicializar a gcloud CLI, execute o seguinte comando:

gcloud init

1. 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: Production
   • Escolher região e disponibilidade por 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: alta memória, 16 vCPU, 104 GB. 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 comparativos 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 privado
     • 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. Use 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 de OLTP de sua escolha, você precisa de uma máquina cliente com potência de CPU significativa na mesma zona da 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 o comparativo de mercado do AlloyDB, desde que o seguinte seja verdadeiro:

   • A máquina cliente está localizada na mesma zona da 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 comparativo de mercado, você reutilizou as máquinas cliente quando elas estavam localizadas na mesma zona da instância principal e quando eram grandes o suficiente para levar o servidor à capacidade máxima.

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

A seguir

• Monitore a performance da instância do AlloyDB.