在 AlloyDB for PostgreSQL 上对 OLTP 性能进行基准测试

本文档介绍如何配置 AlloyDB for PostgreSQL 及客户端机器，以使用 OLTP 基准规范 TPC-C 对 AlloyDB 的性能进行基准测试。本文档还介绍了如何运行自定义的读写密集型 OLTP 场景，例如 Index Insert Only 和 Select Only。

本文档中的说明基于采用特定配置的 AlloyDB 及客户端机器。对于基准测试说明中的每个步骤，都请使用我们提供的值。

AlloyDB 工作负载功能

AlloyDB 可提供企业级的可靠性、可伸缩性及优异性能，适合所有企业及关键工作负载使用。AlloyDB 提供以下组件及功能，可为事务型 (OLTP)、分析型 (OLAP) 及混合型 (HTAP) 工作负载实现高性能：

• 日志和事务管理
• 动态内存管理
• 人工智能和机器学习集成
• 内置列式引擎
• 多层缓存
• 可扩缩的分布式存储

关系型数据库系统通常需要数据库管理员针对基准测试优化数据库，涉及配置事务日志设置、确定合适的缓冲区池大小，以及修改其他数据库参数、标志和特性。这些设置因实例大小和类型而异。

AlloyDB 预先配置了针对每种机器类型优化的设置。AlloyDB 不需要您在数据库级层调整标志即可实现高 OLTP 性能；而且，AlloyDB 还内置了高 OLTP 性能。

注意：结果的准确性可能会因多种因素而异，包括 AlloyDB 实例的类型、运行基准测试的客户端机器的类型以及测试时的区域、可用区和网络带宽。

支持的基准测试类型

本文档介绍了如何使用以下工具运行 OLTP 基准测试：

OLTP 基准测试驱动程序	使用场景
HammerDB	HammerDB 会根据每分钟事务数 (TPM) 来衡量系统性能，并生成包含详细统计信息和性能指标的报告。 HammerDB 支持对基准测试参数进行自定义，可让您调整数据库大小、仓库数量和其他工作负载特性，以模拟不同的场景。 HammerDB 包含 TPC-C 基准测试实现，可用于评估 OLTP 系统的性能。借助 HammerDB TPC-C 实现，您可以模拟类似于 TPC-C 基准测试的工作负载，包括模仿批发供应商环境行为的混合事务。
pgbench	pgbench 是随 PostgreSQL 捆绑提供的基准测试工具。借助 pgbench，您可以模拟事务工作负载（例如插入、更新、选择数据），并以每秒事务数 (TPS) 来衡量数据库系统的性能。 使用 pgbench 时，您可以自定义数据库大小、客户端数量和事务组合，以模拟生产工作负载，并深入了解系统在不同场景下的行为。 pgbench 包含 TPC-B 实现。该 pgbench TPC-B 实现与 TPC-B 基准测试类似。

准备工作

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.

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.

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. 启用创建和连接到 AlloyDB for PostgreSQL 所需的 Cloud API。

   启用 API

   1. 在确认项目步骤中，点击下一步以确认您要更改的项目的名称。

   2. 在启用 API 步骤中，点击启用以启用以下内容：

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

      如果您计划使用与 AlloyDB 位于同一 Google Cloud 项目中的 VPC 网络配置与 AlloyDB 的网络连接，则需要使用 Service Networking API。

      如果您计划使用位于其他 Google Cloud 项目中的 VPC 网络配置与 AlloyDB 的网络连接，则需要使用 Compute Engine API 和 Cloud Resource Manager API。

设置并预配数据库和客户端机器

创建 AlloyDB 集群和实例，以便开始进行基准测试。除非另有说明，否则本文档中的信息均基于 16 vCPU 和 128 GB RAM 的主 AlloyDB 实例。

创建 AlloyDB 集群和实例

1. 前往集群页面。

   转到集群

2. 点击创建集群。

3. 在集群 ID 字段中，为集群输入一个名称。

4. 在可用区级可用性中，为集群类型选择多个可用区（高可用性）。

5. 选择默认网络。

6. 在数据库版本字段中，选择 PostgreSQL 16。

7. 记下主可用区的位置和专用 IP 地址。不要创建读取池。

   注意：本基准测试教程是在没有读取池的情况下进行的。此外，实例必须是多可用区高可用性实例。

8. 点击创建集群。

预配客户端机器

如要运行 OLTP 基准测试，您需要一台具有足够处理能力的客户端机器。HammerDB 和 pgbench 等基准测试工具以高度并行的方式运行，会消耗大量 CPU。运行 OLTP 基准测试时，客户端机器不能成为制约因素。

除非另有说明，否则本文档中的说明均使用配备 128 GB 磁盘的 E2-standard-32 机器作为 OLTP 基准测试的客户端机器，来运行配备 16 个 vCPU 和 128 GB RAM 的 AlloyDB 实例。您必须在与 AlloyDB 主实例相同的可用区中创建客户端机器。

重要提示：如需运行本文档中所述的 OLTP 基准测试，您必须在与 AlloyDB 主实例相同的区域、可用区和 VPC 中预配 Debian Linux 客户端。基准测试工具会通过专用 IP 访问 AlloyDB 实例。

如需在具有 16 个虚拟 CPU 的 AlloyDB 主实例上运行 TPC-C 基准测试，请按照以下步骤创建 Compute Engine 虚拟机并预配客户端机器：

1. 在 Google Cloud 控制台中，前往虚拟机实例页面。

   转到“虚拟机实例”

2. 选择要连接到的 AlloyDB 实例所属的项目。
3. 点击创建实例。
4. 点击机器配置部分。
5. 输入实例的名称。
6. 配置要在其中创建实例的可用区。该可用区必须与 AlloyDB 主实例的可用区相同。
7. 选择 e2-standard-32 机器类型。
8. 保留操作系统和存储空间部分中的默认值。
9. 点击网络部分，并将网络接口设置为配置了 AlloyDB 专用服务访问通道的 VPC 网络。
   如果网络接口未设置为该配置了专用服务访问通道的 VPC 网络，请展开该选项，然后将网络设置为相应 VPC 网络。
10. 保留可观测性部分中的默认值。
11. 点击安全部分。
12. 在身份和 API 访问权限中，将访问权限范围设置为授予对所有 Cloud API 的完整访问权限。
13. 保留高级部分中的默认值。
14. 点击创建。
15. 创建虚拟机后，使用 SSH 连接到您创建的 Compute Engine 虚拟机。

设置基准测试驱动程序机器

安装并设置数据库和客户端机器后，您需要配置在 Google Cloud上运行的客户端机器，您将在该机器上安装 HammerDB 和 pgbench 等基准测试工具。

如需设置基准测试驱动程序机器，请按以下步骤操作：

1. 使用以下 gcloud compute ssh 命令连接到客户端机器：

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

2. 安装 PostgreSQL 客户端。

   1. 使用以下命令安装包含 psql 应用的 PostgreSQL 客户端，然后确保您能够建立连接。

      sudo apt-get update
      sudo apt install postgresql-client

   2. 使用以下命令确保客户端正常运行，并且您能够连接到 AlloyDB。使用 AlloyDB 主实例的专用 IP 地址。

      psql -h PRIVATE_IP -U postgres

3. 运行以下命令，安装可用于进行 TPC-C 基准测试的 HammerDB-4.6 驱动程序：

   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. 运行以下命令，安装可用于进行 TPC-B 及各种 OLTP 基准测试的 pgbench 驱动程序：

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

   如果 pgbench --version 能够正常运行而没有出错，则表示已安装 pgbench。

执行基准测试清理

如果您计划连续执行多个基准测试，则必须在每次基准测试之间执行基准测试清理，以确保基准测试结果准确可靠。

基准测试清理可确保之前执行的基准测试的残留效应不会影响新基准测试的性能衡量结果。基准测试清理还有助于确保基准测试结果的一致性和可重复性，这对于在不同系统之间进行有意义的比较或确定硬件、软件或配置中需要优化的方面而言至关重要。

在运行另一个基准测试之前，请按照以下步骤执行基准测试清理：

1. 删除之前的基准测试数据或基准测试数据库。如需删除之前的基准测试数据库，请在客户端机器上使用以下 psql 命令：

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

   如需详细了解如何使用 psql，请参阅连接到数据库。

2. 重启 AlloyDB 实例。此步骤会在数据库及操作系统级清除缓存。

运行 TPC-C 基准测试

HammerDB 是一款包含 TPC-C 基准测试实现的基准测试工具，该实现可用于评估 OLTP 系统的性能。借助 HammerDB 的 TPC-C 实现，您可以模拟类似于 TPC-C 基准测试的工作负载，包括模仿批发供应商环境行为的混合事务。

HammerDB 会根据每分钟事务数 (TPM) 来衡量系统性能，并生成包含详细统计信息和性能指标的报告。此外，HammerDB 还支持对基准测试参数进行自定义，让用户可以调整数据库大小、仓库数量和其他工作负载特性，以模拟不同的场景。

性能评估场景

TPC-C 基准测试的性能评估方法如下：

• 部分缓存模式（约 30%）：在此模式下，系统会生成一个大型 TPC-C 数据库，该数据库只能部分放入缓冲区缓存中。此模式下的事务并不总是通过内存进行处理，并且会产生对底层存储子系统的 I/O 需求。此场景适合用来评估用户众多的 OLTP 需求。

• 完全缓存模式 (100%)：在此模式下，TPC-C 数据库会完全放入缓冲区缓存中。AlloyDB 实例会使用 128 GB 可用 RAM 的大约 90%，包括缓冲区缓存。

  由于 TPC-C 事务所需执行的 I/O 极少（因为读取操作大多通过缓冲区缓存进行处理），因此，此模式与部分缓存模式相比，TPM 预计会更高。此场景适合用来评估 I/O 需求非常低的用户的 OLTP 需求。

设置客户端机器

1. 设置基准测试驱动程序机器。

2. 如果您要连续运行多个基准测试，请执行基准测试清理。

3. 运行以下命令，打开 hammerdb/HammerDB-4.6 directory：

   cd hammerdb/HammerDB-4.6

   您将从此目录运行命令来设置客户端机器。

4. 使用以下命令创建 setup.env 文件：

   注意：如果您使用的是托管式连接池，请将端口号从 5432 更改为 6432。该项设置适用于本页面上的所有示例。

   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

   注意：用户（或客户端）数量已设置为 256。此用户数量参数经过调优，可在部分缓存及完全缓存配置中提供最佳吞吐量，并且延迟时间也在可接受范围内。

5. 修改生成的 setup.env 文件，将所有突出显示的参数值替换为最适合您的环境设置的参数值。

6. 可选：通过将 setup.env 文件中的 NUM_WAREHOUSE 更改为 3200，测试部分缓存模式（约 30%）。如需了解详情，请参阅性能评估场景。

7. 可选：通过将 setup.env file 中的 NUM_WAREHOUSE 更改为 576，测试完全缓存模式 (100%)。如需了解详情，请参阅性能评估场景。

将 TPC-C 数据加载到数据库中

“加载步骤”是指在运行性能测试之前，使用初始数据填充基准测试数据库的过程。

在加载步骤中，系统会根据 TPC-C 规范，在数据库中填充指定数量的仓库、客户和其他实体。执行加载步骤是为了为性能测试创建具有实际意义的工作负载，并确保测试结果在不同系统之间具有可比性。

加载步骤完成后，数据库将处于一致状态，会包含一组预定义的初始数据，之后这些数据将用于进行 TPC-C 基准测试。

如需加载 TPC-C 数据库，请按以下步骤操作：

1. 使用以下命令切换到基准测试主目录：

   cd hammerdb/HammerDB-4.6

2. 复制以下内容，然后将其粘贴到 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. 执行以下加载命令，并等待该命令完成。

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

4. 验证加载内容。上一个脚本完成后，建议您确认数据库加载是否成功。如需验证数据库大小，请运行以下命令：

   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)
   

在缓存率为 30% 的 TPC-C 配置（包含 3200 个仓库）中，tpcc 数据库的大小预计约为 300 GB。

在缓存率为 100% 的 TPC-C 配置（包含 576 个仓库）中，tpcc 数据库的大小预计约为 55 GB。

运行 TPC-C 基准测试

您现在可以运行 TPC-C 性能测试了。TPC-C 基准测试使用负载步骤中填充的数据库来执行。该基准测试会生成一系列模拟典型业务环境的交易，包括订单输入、付款处理和库存管理。工作负载则以每分钟事务数 (TPM) 进行衡量，该指标表示系统在一分钟内可以处理的完整业务交易的数量。

执行运行步骤是为了模拟实际条件对数据库系统施加压力，并提供一种标准衡量方式来比较不同数据库系统的性能。供应商和用户通常会使用 TPC-C 基准测试的结果来评估不同数据库系统和硬件配置的性能。

注意：以下脚本在预热约 10 分钟后，会运行 TPC-C 基准测试约 1 小时。

如需运行 TPC-C 基准测试，请按以下步骤操作：

1. 切换到基准测试主目录：

   cd hammerdb/HammerDB-4.6

2. 复制以下内容，然后将其粘贴到 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. 使用以下命令运行脚本：

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

4. 等待 run-tpcc.sh 脚本完成。该脚本大约需要 1 小时 10 分钟才能完成。脚本完成后，您便可以分析结果。

分析基准测试结果

在 TPC-C 基准测试中，每分钟新订单数 (NOPM) 和每分钟事务数 (TPM) 是用于衡量数据库系统性能的性能指标。

• NOPM：衡量系统在一分钟内可处理的新订单事务的数量。新订单事务是 TPC-C 基准测试中最重要的事务之一，涉及为客户创建新订单。

• TPM：衡量系统在一分钟内可处理的已完成业务事务的总数。这些事务包括新订单事务以及 TPC-C 基准测试中定义的其他类型的事务，例如付款、送货和订单状态。

  TPM 是 TPC-C 基准测试的主要性能指标，因为它可全面衡量系统处理实际工作负载的能力。对于专注于处理新订单的系统（例如电子商务或零售系统），NOPM 会是一个非常有用的指标。

在 16 vCPU 机器上查看缓存率为 30% 的 TPC-C 数据库的结果

如需提取此场景的性能数据，请使用以下命令：

grep NOPM results/run-tpcc.out

以下是预期输出：

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

在 16 vCPU 机器上，对于缓存率为 30% 的 TPC-C 数据库（NUM_WAREHOUSE=3200 且 NUM_USERS=256），累计 AlloyDB TPM 为 582,385，其中 tpm-C（每分钟新订单数）为 252,970。

在 16 vCPU 机器上查看缓存率为 100% 的 TPC-C 数据库的结果

在 16 vCPU 机器上，对于缓存率为 100% 的 TPC-C 数据库（NUM_WAREHOUSE=576 且 NUM_USERS=256），累计 AlloyDB TPM 为 974,264，其中 tpm-C（每分钟新订单数）为 428,316。

如需提取此场景的性能数据，请使用以下命令：

grep NOPM results/tpcc-run.out

以下是预期输出：

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

16 vCPU 机器上的性能结果摘要

下表总结了 16 vCPU 机器的基准测试性能结果：

TPC-C 场景	NUM_WAREHOUSE	NUM_USERS	NOPM	累计 TPM
30% 缓存率	3200	256	252,970	582,385
100% 缓存率	576	256	428,316	974,264

观测数据库性能指标

如要进一步了解数据库系统的行为，可以使用 AlloyDB 监控工具来观测重要的系统指标，例如 CPU 用量、内存用量和每秒事务数。如需了解详情，请参阅监控实例性能。

例如，在运行此基准测试后，您可以在 Google Cloud 控制台的 AlloyDB 概览页面中看到，在缓存率为 100% 的 TPC-C 基准测试中，平均 CPU 利用率接近 90%。

在 64 vCPU AlloyDB 实例上运行 TPC-C 基准测试

如要在 64 vCPU AlloyDB 实例上运行 TPC-C 基准测试，按照运行 TPC-C 基准测试部分的相同设置步骤操作即可，不过需要更改为相应的机器类型。

设置 AlloyDB 和客户端机器

1. 创建 AlloyDB 集群和实例，并将 64 vCPU, 512GB 设置为机器类型。

2. 预配客户端机器，并将 n2-standard-64 设置为机器类型。

3. 设置基准测试驱动程序机器。

运行基准测试

1. 如果您要连续运行多个基准测试，请执行基准测试清理。

2. 设置客户端机器，替换以下值：

   • 将 PGHOST 设置为新 64 vCPU AlloyDB 实例的专用 IP。
   • 对于缓存率为 30% 的 TPC-C 场景，请设置 NUM_WAREHOUSE=12800 和 NUM_USERS=1024。
   • 对于缓存率为 100% 的 TPC-C 场景，请设置 NUM_WAREHOUSE=2304 和 NUM_USERS=1024。

3. 设置并加载 TPC-C 数据库。如需加快加载速度，请将 build-tpcc.sh 中 pg_num_vu 的值更改为 64，如 diset tpcc pg_num_vu 64 所示。

4. 运行 TPC-C 基准测试。

分析基准测试结果

下表总结了 64 vCPU 机器上的基准测试性能结果：

基准测试模式	NUM_WAREHOUSE	NUM_USERS	NOPM	累计 TPM
30% 缓存率	12800	1024	589,598	1,371,160
100% 缓存率	2304	1024	716,138	1,665,438

运行 pgbench TPC-B 基准测试

TPC-B（事务处理性能委员会基准测试 B）是 PostgreSQL 基准测试工具 pgbench 中提供的一种基准测试模式。TPC-B 模拟的是一种银行场景，假定有多个柜员对客户账号进行事务处理。工作负载包含以下类型的事务：

• 存款
• 取款
• 余额查询

该基准测试通过模拟这些事务的组合并衡量系统每秒可处理的事务数来衡量数据库系统的性能。

pgbench 中的 TPC-B 模式会生成一个合成数据库，并模拟类似于 TPC-B 工作负载的混合事务，不过该模式尚未获得 TPC 组织的正式认证。因此，尽管 pgbench 中的 TPC-B 模式可以非常接近 TPC-B 性能，但请勿用它来声称符合 TPC-B 标准。

性能衡量场景

本部分介绍如何衡量以下关键模式下的 TPC-B 性能。这些模式唯一不同的参数是 SCALE_FACTOR 参数值。

部分缓存的数据库场景

在此场景中，您将使用 --scale= 50000 设置并初始化一个大型数据库（大小约为 650 GB）。由于该大型数据库无法完全放入内存且会导致大量的磁盘 I/O 需求，因此可以真实地反映许多生产环境下的工作负载状况。

如果数据库很庞大，导致磁盘 I/O 需求显著增加，则可以凸显数据库设计和查询优化的重要性。大型数据库还可能会暴露与磁盘 I/O 相关的性能问题，例如磁盘访问速度慢或查询效率低，这些问题在小型数据库或完全驻留在内存中的数据库中可能并不明显。

完全缓存的数据库场景

在此场景中，您将使用 --scale=4000 设置并初始化一个大小约为 60GB 的数据库，以便该数据库驻留在缓冲区池中。对内存驻留型数据库进行基准测试非常重要，因为这样可以在受控环境中评估数据库系统的最高性能。

内存驻留型数据库会将所有数据存储在 PostgreSQL 缓冲区池中，从而消除从磁盘访问数据所带来的 I/O 制约。此模式有助于识别与 I/O 无关的性能制约因素，例如 CPU 利用率或锁定问题，在对依赖于磁盘 I/O 的数据库进行基准测试时，这些问题可能并不明显。

设置数据库服务器和客户端机器

如需设置运行 pgbench TPC-B 基准测试的基础设施，请按以下步骤操作：

1. 创建 AlloyDB 集群和实例，并将 16 vCPU, 128GB 设置为机器类型。

2. 预配客户端机器，并将 E2-standard-16 (minimum) 设置为机器类型。

3. 设置基准测试驱动程序机器。

4. 执行基准测试清理。

运行 pgbench TPC-B 基准测试

重要提示：我们建议您运行该基准测试的时间稍长一些，因为在最初的几秒内吞吐量较低，需要一段时间才能达到稳定状态。

1. 使用以下 Google Cloud CLI 命令连接到客户端机器：

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

2. 创建 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. 修改生成的 setup.env 文件，并将以下参数值替换为适合您环境设置的值。

   • PRIVATE_IP：AlloyDB 实例的专用 IP。

   使用下表选择 <scale_factor> 和 <num_clients> 值。这些值必须随机器类型和数据库大小（完全缓存或部分缓存）进行调整。本指南中的示例使用与 n2-highmem-16 机器类型对应的 SCALE_FACTOR 和 NUM_CLIENT 值。

   	完全缓存		部分缓存
   机器类型	SCALE_FACTOR	NUM_CLIENTS	SCALE_FACTOR	NUM_CLIENTS
   n2-highmem-2	500	48	6250	32
   n2-highmem-4	1000	96	12500	64
   n2-highmem-8	2000	192	25000	128
   n2-highmem-16	4000	384	50000	256
   n2-highmem-32	8000	768	100000	512
   n2-highmem-64	16000	1536	200000	1024

4. 创建 pgbench 数据库。

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

5. 运行以下命令，初始化并加载 pgbench 数据库。此步骤可确保创建基准测试数据集并使用具有实际意义的数据填充该数据集，从而让您能够在 pgbench 数据库上准确模拟 TPC-B 工作负载。

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

   预计加载时间：

   • 部分缓存的数据库大约需要 6 小时才能加载完毕。
   • 完全缓存的数据库大约需要 45 分钟才能加载完毕。

6. 可选：执行加载准确性检查，确保 /tmp/pgbench-tpcb-partially-cached-db-init.out 文件的内容与以下内容类似：

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

7. 可选：如需进一步验证加载内容的准确性，请运行以下 PostgreSQL 命令来衡量所有 pgbench 表的大小：

   1. 连接到 pgbench 数据库：

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

   2. 运行以下 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. 将上一个命令的输出与您从部分缓存的数据库运行 (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. 运行以下命令，通过执行一系列涉及存款、转账和付款的事务来模拟财务会计系统工作负载，从而衡量数据库在密集型工作负载下的性能。

   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
   

分析基准测试结果

在 ~/results/alloydb/pgbench/pgbench.run.out 文件中检查上一个命令的输出。相应 TPS 数值应接近完全缓存数据库及部分缓存数据库场景中显示的数值。

完全缓存数据库的结果

运行 pgbench TPC-B 基准测试部分最后一个命令的输出应类似于以下内容，其中 --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)

如要进一步了解数据库系统的行为，可以使用 Google Cloud 控制台监控 CPU 用量、内存用量和每秒事务数等系统指标。如需了解详情，请参阅监控实例。

部分缓存数据库的结果

运行 pgbench TPC-B 基准测试部分最后一个命令的输出应类似于以下内容，其中 --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)

pgbench TPC-B 基准测试的性能结果摘要

下表总结了 pgbench TPC-B 基准测试的性能结果：

TPC-B 场景	SCALE_FACTOR	TPS	CPU 利用率 (%)
部分缓存	50000	17,460	96%
完全缓存	4000	21,750	94%

运行“Index Insert Only”基准测试

“Index Insert Only”基准测试是一种高度并发、写入密集型的场景，本部分将对其进行自定义，以展示 AlloyDB 能够为大多数 OLTP 应用提供的性能优势。如要运行此基准测试，您需要在 pgbench_history 表上创建多个索引，然后通过多个客户端连接对 pgbench_history 表重复执行 INSERT 操作。

“Index Only Insert”基准测试用于衡量将数据插入数据库表时的性能，重点关注索引对写入操作的影响。此基准测试可让您了解在有索引和无索引的情况下，向表中添加新行的速度，能够凸显在插入期间因索引维护而造成的速度减慢。

AlloyDB 可提升 PostgreSQL 的写入性能，从而改进 OLTP 工作负载的性能。为了提升写入密集型 OLTP 场景的性能，AlloyDB 引入了多项架构创新，包括用于改进读取性能的分层缓存层，以及用于改进写入性能的高度可扩缩分布式存储引擎技术。

设置 AlloyDB 和客户端机器

如需设置运行“Index Only Insert”基准测试的基础设施，请按以下步骤操作：

1. 创建 AlloyDB 集群和实例，并将 16 vCPU and 128 GB RAM 设置为机器类型。

2. 预配客户端机器，并将 E2-standard-16 (minimum) 设置为机器类型。

3. 设置基准测试驱动程序机器。

4. 执行基准测试清理。

运行“Index Insert Only”基准测试

1. 使用以下示例命令连接到客户端机器：

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

2. 运行以下命令来设置环境：

   export PGHOST=<private_ip>
   

   重要提示：请从同一客户端终端运行此过程中的所有剩余命令。然后，您只需导出 PGHOST 环境变量一次，并将其分配给 AlloyDB 实例的专用 IP。如果您将多个终端连接到客户端机器，请在所有终端上导出以下环境变量。

3. 使用以下示例创建 pgbench 数据库。如果数据库已存在，请将其删除并重新创建。

   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. 初始化并加载 pgbench 数据库，以确保已创建基准测试数据集并填充了具有实际意义的数据。修改突出显示的参数，然后运行以下命令：

   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. 验证上一个命令的输出是否类似于以下内容：

   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. 使用以下命令创建 index-init.sql 脚本：

   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. 执行 index-init.sql 脚本：

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

8. 可选：验证数据库架构和初始加载内容：

   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)
   

   加载后，数据库大小预计约为 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. 使用以下命令创建 index-inserts-only.sql 脚本：

   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. 使用以下命令运行 pgbench 基准测试：

    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

分析基准测试结果

在 /tmp/pgbench-index-insert-only-run.out 文件中验证上一个命令的输出。在此基准测试期间，您应该会看到大约每秒 5.2 万笔事务，CPU 利用率约为 88%，如以下示例输出所示。

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)

在 64 vCPU 实例上运行“Select Only”基准测试

pgbench 支持内置的“Select Only”场景，该场景会通过多个客户端连接对指定数据库重复执行 SELECT 查询。此基准测试用于衡量数据库的读取性能，而不会引入 INSERT、UPDATE 或 DELETE 等数据修改操作开销。这些 SELECT 查询属于点查找查询，是速度最快、效率最高的 SELECT 查询类型，因为它们仅涉及直接从索引结构访问单行数据。

运行“Select Only”基准测试有助于您实现以下目标：

• 实现最大吞吐量：由于索引上的点查找是数据库系统中最高效的查询形式，因此您可以衡量 AlloyDB 可以实现的最大可能吞吐量。

• 可伸缩性：“Select Only”基准测试有助于您测试 AlloyDB 的可伸缩性，可以从 2 vCPU 一直测试到 AlloyDB 可提供的最大 vCPU 配置。

设置 AlloyDB 和客户端机器

在 64 vCPU 机器类型上设置 AlloyDB 和客户端机器。

运行“Select Only”基准测试

1. 使用以下示例命令连接到客户端机器：

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

2. 使用以下命令设置环境：

   export PGHOST=<private_ip>
   

   重要提示：请从同一客户端终端运行此过程中的所有剩余命令。然后，您只需导出 PGHOST 环境变量一次，并将其分配给 AlloyDB 实例的专用 IP。如果您将多个终端连接到客户端机器，请在所有终端上导出以下环境变量。

3. 使用以下示例创建 pgbench 数据库：

   psql -h $PGHOST -p 5432 -U postgres
   
   postgres=> create database pgbench;
   CREATE DATABASE
   

4. 初始化 pgbench 数据库。以下命令会使用大约 220 GB 的实际数据初始化 pgbench 数据库。您可以使用 --scale=15000 来运行完全缓存的“Select Only”基准测试。

   运行以下命令：

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

5. 验证上一个命令的输出是否类似于以下内容：

   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. 运行 pgbench。这最后一个基准测试步骤需要一个多小时才能完成。

   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. 基准测试完成后，请检查 /tmp/pgbench-select-only-run.out 文件中的最终结果。

分析基准测试结果

在此基准测试期间，您应该会看到每秒约 46.7 万笔事务，CPU 利用率约为 95%，如以下示例输出所示。

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)

AlloyDB 基准测试结果摘要

下表总结了基于本文档中执行的测试的 AlloyDB 基准测试结果。

HammerDB TPC-C 性能摘要

AlloyDB 机器类型	TPC-C 工作负载场景	NUM_WAREHOUSE	NUM_USERS	每分钟新订单数 (NOPM)	累计 TPM	TPS 转换值
16vCPU	30% 缓存率	3200	256	252,970	582,385	9,706
16vCPU	100% 缓存率	576	256	428,316	974,264	16,238
64vCPU	30% 缓存率	12800	1024	589,598	1,371,160	22,853
64vCPU	100% 缓存率	2304	1024	716,138	1,665,438	27,757

pgbench 性能摘要

AlloyDB 机器类型	pgbench 工作负载场景	规模系数	TPS	CPU 利用率 (%)
16vCPU	类似于 TPC-B，完全缓存	4000	20,359	96%
16vCPU	类似于 TPC-B，部分缓存	50000	14,060	94%
16vCPU	Index Insert Only	25000	51,742	88%
64vCPU	最大吞吐量 (Select Only)	15000	467,583	95%

在 Cloud SQL for PostgreSQL 上运行 OLTP 基准测试

您可以在 Cloud SQL for PostgreSQL 中测试 PostgreSQL 在 16 vCPU 机器类型上的等效 OLTP 性能，以便进行对比分析。本部分介绍如何设置 Cloud SQL for PostgreSQL（或部署在您选择的基础架构上的任何 PostgreSQL 服务器），使其与本指南中用来对 OLTP 性能进行基准测试的 AlloyDB 设置相当。此场景涉及选择 16vCPU SKU、启用高可用性 (HA) 以及预配置存储空间。

准备工作

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.

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.

如果您使用的是外部身份提供方 (IdP)，则必须先使用联合身份登录 gcloud CLI。

如需初始化 gcloud CLI，请运行以下命令：

gcloud init

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

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.

如果您使用的是外部身份提供方 (IdP)，则必须先使用联合身份登录 gcloud CLI。

如需初始化 gcloud CLI，请运行以下命令：

gcloud init

1. 确保您的用户账号具有 Cloud SQL Admin 和 Compute Viewer 角色。

   转到 IAM 页面

   详细了解角色和权限。

预配 Cloud SQL for PostgreSQL 实例

1. 创建 PostgreSQL 实例，并替换以下值：

   • 数据库版本：PostgreSQL 14
   • 首先选择一个配置：生产环境
   • 选择区域及可用区级可用性：选择 us-central1 作为区域。
   • 可用区级可用性：多个可用区（高可用性）
     • 主可用区：us-central1-c
     • 次要可用区：us-central-1-f
   • 机器类型：高内存 16 vCPU、104 GB 机器。这是 Cloud SQL for PostgreSQL 能够提供的与您在本文档的 AlloyDB 基准测试部分中创建的匹配 AlloyDB 实例最为接近的机器配置。
   • 存储空间容量：自定义，1500 GB
     • 启用存储空间自动扩容功能
   • 加密： Google-owned and Google-managed encryption key
   • 连接：专用 IP
     • 网络：default
     • 公共 IP：已启用

2. 点击创建实例。

3. 创建 PostgreSQL 实例后，记下专用 IP 地址。您将使用该 IP 地址作为 PGHOST 来建立与基准测试的连接。

预配客户端机器

1. 预配 Cloud SQL for PostgreSQL 实例。如要运行您选择的 OLTP 基准测试，您需要有一台 CPU 性能出色的客户端机器，该机器应与 Cloud SQL 中的主 Cloud SQL for PostgreSQL 实例位于同一可用区。

2. 可选：作为上一步的替代方案，您还可以使用为 AlloyDB 基准测试设置的同一客户端机器，前提是满足以下条件：

   • 客户端机器与新的 PostgreSQL (Cloud SQL for PostgreSQL) 主实例位于同一可用区。
   • 客户端机器满足最低 CPU、RAM 和磁盘大小要求。

   在本基准测试指南中，我们有可能会重复使用客户端机器，前提是它们与主实例位于同一可用区，并且容量足够大，能够支持服务器的最大容量。

3. 如果您创建了新的客户端机器，请相应设置基准测试驱动程序机器。否则，请按照本指南中相关基准测试的说明进行操作。

后续步骤

• 监控 AlloyDB 实例性能。