Comparação de desempenho OLTP no AlloyDB para PostgreSQL

Para avaliar a capacidade de processamento e a latência das cargas de trabalho transacionais no AlloyDB para PostgreSQL, configure o AlloyDB e uma máquina cliente para comparar o desempenho do processamento de transações on-line (OLTP) usando TPC-C, uma especificação de comparativo de mercado de OLTP padrão do setor. Também é possível executar cenários OLTP personalizados com uso intensivo de leitura e gravação, como Somente inserção de índice e Somente seleção.

As instruções neste documento são baseadas em uma configuração específica do AlloyDB e da máquina cliente. Use os valores fornecidos para cada etapa nas instruções de 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 em vários níveis
  • Armazenamento distribuído e escalonável

Os sistemas de banco de dados relacional normalmente exigem que um administrador de banco de dados otimize o banco de dados para comparativo de mercado, o que inclui definir as configurações do registro de transações, estabelecer os tamanhos certos do pool de buffers e modificar outros parâmetros ou 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 as flags no nível do banco de dados para alcançar um alto desempenho de OLTP. Em vez disso, o AlloyDB tem um alto desempenho de OLTP integrado.

Tipos de comparativo 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 Casos de uso
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 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 warehouses 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 do 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 que vem com o PostgreSQL. Com ele, é possível simular cargas de trabalho de transações, 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, na sigla em inglês).

Ao usar o pgbench, é possível personalizar o tamanho do banco de dados, o número de clientes e a combinação de transações para emular 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 de TPC-B. A implementação do TPC-B do pgbench é semelhante a um comparativo de mercado do TPC-B.

Antes de começar

  1. Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho sem custos financeiros.

  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 role (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. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. 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 role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

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

  7. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

    8.

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

    Ativar as APIs

    1. Na etapa Confirmar projeto, clique em Avançar para confirmar o nome do projeto em que você vai fazer alterações.

    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 do Google Cloud 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 do Google Cloud diferente.

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

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

Criar um cluster e uma instância do AlloyDB

  1. Acesse a página Clusters.

    Acessar Clusters

  2. Clique em Criar cluster.

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

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

  5. Selecione a rede padrão.

  6. No campo Versão do banco de dados, selecione uma das seguintes opções:

    • PostgreSQL 17

    • PostgreSQL 18

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

  8. Clique em Criar cluster.

Provisionar a máquina cliente

Para executar comparativos de mercado de OLTP, é preciso ter 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 OLTP.

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

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

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

    Acessar instâncias de VM

  2. Selecione o projeto que contém a instância do AlloyDB à qual você quer se conectar.
  3. Clique em Criar instância.
  4. Clique na seção Configuração da máquina.
  5. Digite um Nome para a instância.
  6. Configure a zona em que você quer criar a instância. A zona precisa ser a mesma da instância principal do AlloyDB.
  7. Selecione o 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 as Interfaces de rede não estiverem definidas como a rede VPC configurada para acesso a serviços particulares, expanda-as 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 em execução no Google Cloud, em que você instala ferramentas de comparação, como HammerDB e pgbench.

Para configurar a máquina do 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 do 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 principal do AlloyDB.

      psql -h PRIVATE_IP -U postgres

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

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

  4. Instale o driver pgbench para TPC-B e diversos comparativos de mercado 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.

Realizar uma limpeza de comparativo de mercado

Se você planeja executar várias comparações em sequência, faça uma limpeza entre cada uma delas para garantir resultados precisos e confiáveis.

Uma limpeza de comparativo de mercado garante que os efeitos residuais de comparativos de mercado anteriores não afetem as medições de desempenho do novo comparativo de mercado. As limpezas de comparativo de mercado também ajudam a garantir a consistência e a repetibilidade dos resultados do comparativo de mercado, 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 realizar 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 como usar psql, consulte Conectar-se a um banco de dados.

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

Executar um comparativo de mercado TPC-C

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

O HammerDB mede o desempenho do sistema em termos de transações por minuto (TPM) e gera relatórios que incluem estatísticas detalhadas e métricas de performance. Além disso, o HammerDB permite personalizar os parâmetros de comparativo de mercado, permitindo que os usuários ajustem o tamanho do banco de dados, o número de warehouses e outras características da carga de trabalho para simular diferentes cenários.

Cenários de avaliação de desempenho

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

  • Modo parcialmente armazenado em cache (~30%):nesse modo, um grande banco de dados TPC-C é gerado, que só pode caber parcialmente no cache do buffer. As transações nesse modo nem sempre são exibidas 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%) armazenado em cache:nesse modo, o banco de dados TPC-C se encaixa totalmente no cache do 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 realizam E/S mínimas, porque as leituras são, em grande parte, atendidas pelo cache de buffer, nesse modo, espera-se um TPM maior em comparação com as 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 do driver de comparativo de mercado.

  2. Se você estiver executando vários comparativos de mercado em sequência, faça uma limpeza de comparativos de mercado.

  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:

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

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

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

  7. Opcional: teste o modo 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 carregamento se refere ao processo de preenchimento do banco de dados de comparativo de mercado com dados iniciais antes de executar o teste de desempenho.

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

Depois que a etapa de carregamento é concluída, o banco de dados fica em um estado consistente com um conjunto definido de dados iniciais, pronto para ser usado no teste de 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 carregamento a seguir e aguarde a conclusão.

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

  4. Valide o carregamento. 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 armazenamento em cache (com 3.200 warehouses), o tamanho do banco de dados tpcc é de cerca de 300 GB.

Na configuração TPC-C 100% armazenada em cache (com 576 warehouses), o tamanho do banco de dados tpcc é de cerca de 55 GB.

Executar o comparativo de mercado TPC-C

Agora você já pode executar o teste de desempenho do TPC-C. O comparativo de mercado TPC-C é executado usando o banco de dados preenchido da etapa de carregamento. O comparativo de mercado 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 comparada entre diferentes sistemas de banco de dados. Os fornecedores e usuários costumam usar os resultados do comparativo de mercado do TPC-C para avaliar o desempenho de diferentes sistemas de banco de dados e configurações de hardware.

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

  1. Mude para o diretório principal 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 for concluído, você poderá analisar os resultados.

Analisar os resultados do comparativo de mercado

No comparativo de mercado do TPC-C, os novos pedidos por minuto (NOPM, na sigla em inglês) e as transações por minuto (TPM, na sigla em inglês) são métricas de 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 de mercado TPC-C e envolve a criação de um novo pedido para um cliente.

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

    O TPM é a principal métrica de performance para o comparativo de mercado 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 armazenado em cache em uma máquina com 16 vCPUs

Para extrair os números de desempenho 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 um banco de dados TPC-C de 30% em cache em uma máquina de 16 vCPUs (com NUM_WAREHOUSE=3200 e NUM_USERS=256), você observa 252.970 tpm-C (novo pedido por minuto) de um TPM cumulativo de 582.385 do AlloyDB.

Ver resultados com o 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 (novo pedido por minuto) de um TPM cumulativo de 974.264 do AlloyDB.

Para extrair os números de desempenho 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 desempenho 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 do 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 performance 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 de mercado, é possível observar na página Visão geral do AlloyDB no console do Google Cloud que a utilização média da CPU para a execução do TPC-C 100% armazenada em cache é de quase 90%.

Executar um comparativo de mercado 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áquina diferentes.

Configurar o AlloyDB e a máquina cliente

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

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

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

Executar a comparação

  1. Se você estiver executando vários comparativos de mercado em sequência, faça uma limpeza de comparativo de mercado.

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

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

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

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

Executar um comparativo de mercado TPC-B do pgbench

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 o 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
  • Saques
  • 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 combinação de transações que se assemelha à carga de trabalho do 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 conformidade com os padrões do TPC-B.

Cenários para medir a performance

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

Cenário de banco de dados parcialmente armazenado em cache

Neste cenário, você configura e inicializa um banco de dados grande (com aproximadamente 650 GB) usando o --scale= 50000. Ter um banco de dados grande que não cabe na memória e causa uma 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 uma E/S de disco significativa pode destacar 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 o --scale=4000 para que ele resida no pool de buffers. O comparativo de mercado de um banco de dados residente na memória é importante porque permite avaliar o desempenho máximo do sistema de banco de dados em um ambiente controlado.

Um banco de dados residente na memória armazena todos os dados no pool de buffers do PostgreSQL, eliminando o gargalo de E/S que pode ocorrer ao acessar dados do disco. Esse modo pode ajudar a identificar gargalos de desempenho que não estão relacionados à E/S, como uso de CPU ou problemas de bloqueio, que podem não ser aparentes ao comparar 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 mercado 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 do driver de comparativo de mercado.

  4. Realize uma limpeza de comparação.

Executar o comparativo de mercado TPC-B do pgbench

  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 seguinte valor de parâmetro por valores adequados à configuração do ambiente.

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

    Use a tabela a seguir para escolher os valores de <scale_factor> e <num_clients>. Esses valores precisam ser escalonados de acordo com o tipo de máquina e o tamanho do banco de dados (total 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 1536 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 comandos a seguir. Essa etapa garante que o conjunto de dados de comparativo de mercado 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 carregar.

  6. Opcional: verifique a precisão do carregamento garantindo que o conteúdo do arquivo /tmp/pgbench-tpcb-partially-cached-db-init.out seja semelhante ao seguinte:

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

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

    1. Conecte-se ao banco de dados pgbench:

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

    2. Execute o seguinte comando SQL:

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

    3. Compare a saída do comando anterior com a saída que você recebeu para a execução do banco de dados parcialmente 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 do sistema de contabilidade financeira executando uma série de transações que envolvem 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 do comparativo de mercado

Verifique a saída do comando anterior no arquivo ~/results/alloydb/pgbench/pgbench.run.out. O número de TPS precisa ser próximo aos números mostrados nos cenários de banco de dados totalmente armazenado em cache e parcialmente armazenado 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 precisa 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 precisa ser semelhante ao seguinte, em que --scale=50000:

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

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

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

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

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

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

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

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

O AlloyDB melhora o desempenho de gravação do PostgreSQL, o que também melhora as cargas de trabalho de OLTP. Para melhorar o desempenho de cenários OLTP com uso intensivo de gravação, o AlloyDB oferece inovações arquitetônicas, 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 para executar um comparativo de mercado de inserção somente de índice, siga estas etapas:

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

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

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

  4. Realize uma limpeza de comparativo de mercado.

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

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

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

  2. Configure o ambiente executando o seguinte comando:

    export PGHOST=<private_ip>

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

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

  4. Inicialize e carregue o banco de dados do 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 cerca de 365 GB:

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

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

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

  10. Execute o comparativo de mercado 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 do comparativo de mercado

Verifique a saída do comando anterior no arquivo /tmp/pgbench-index-insert-only-run.out. Você verá aproximadamente 52 mil transações por segundo e uma taxa de utilização de 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 somente de seleção em uma instância de 64 vCPUs

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

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

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

  • Escalonabilidade: os comparativos de mercado de seleção 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 com 64 vCPUs.

Executar o comparativo de mercado Select Only

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

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

  2. Configure o ambiente usando o seguinte comando:

    export PGHOST=<private_ip>

  3. Crie o banco de dados pgbench usando o seguinte exemplo:

    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. Use --scale=15000 para o comparativo de mercado somente de seleção totalmente armazenado em cache.

    Execute este comando:

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

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

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

  6. Execute o pgbench. Essa etapa final de 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 de mercado for concluído, verifique os resultados finais no arquivo /tmp/pgbench-select-only-run.out.

Analisar os resultados do comparativo de mercado

Você vai observar aproximadamente 467 mil transações por segundo e uma taxa de utilização de 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 do desempenho do HammerDB TPC-C

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

Resumo de desempenho do pgbench

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

Executar comparativo 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) que seja comparável à configuração do AlloyDB usada neste guia para comparar o desempenho do OLTP. Nesse cenário, inclui a escolha da SKU de 16 vCPUs, a ativação da alta disponibilidade (HA) e a pré-configuração com armazenamento.

Antes de começar

  1. Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho sem custos financeiros.

  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 role (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. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. Install the Google Cloud CLI.

  6. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

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

    gcloud init

  8. 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 role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

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

  10. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  11. Install the Google Cloud CLI.

  12. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

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

    gcloud init
  14. 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 a disponibilidade por região e zona: selecione us-central1 como a região.
    • Disponibilidade por zona: várias zonas (altamente disponível)
      • Zona principal: us-central1-c
      • Zona secundária: us-central-1-f
    • Tipo de máquina: máquina de 16 vCPUs e 104 GB de memória alta. 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 comparativo 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 comparativo de mercado.

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 que a instância principal do Cloud SQL para PostgreSQL no Cloud SQL.

  2. Opcional: como alternativa à etapa anterior, use a mesma máquina cliente que você configurou para o comparativo de mercado do AlloyDB, desde que as seguintes condições sejam verdadeiras:

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

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

  3. Se você criou uma nova máquina cliente, configure a máquina do 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