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

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

本文档中的说明基于 AlloyDB 和客户端计算机的特定配置。在基准测试说明中的每个步骤中使用所提供的值。

AlloyDB 工作负载功能

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

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

关系型数据库系统通常需要数据库管理员优化数据库以进行基准测试，这包括配置事务日志设置、建立正确的缓冲区大小，以及修改其他数据库参数或标志和特性。这些设置因实例大小和类型而异。

AlloyDB 预配置了针对每种机器类型的优化设置。使用 AlloyDB，您无需在数据库级别调整标志即可实现高 OLTP 性能；相反，AlloyDB 内置了高 OLTP 性能。

支持的基准测试类型

本文档介绍了如何使用以下工具运行 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 基准。

准备工作

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

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

    Go to project selector

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

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

    Go to project selector

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

  6. 启用创建和连接到 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 集群和实例，然后开始基准测试。除非另有说明，否则本文档中的信息均基于具有 128 GB RAM 的 16 个 vCPU 作为主要 AlloyDB 实例。

创建 AlloyDB 集群和实例

  1. 前往集群页面。

    转到集群

  2. 点击创建集群。

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

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

  5. 选择默认网络。

  6. 在 Database version 字段中，选择 PostgreSQL 15。

  7. 记下主区域的位置和专用 IP 地址。请勿创建读取池。

  8. 点击创建集群。

预配客户端机器

如需运行 OLTP 基准测试，您需要具备足够处理能力的客户端机器。HammerDB 和 pgbench 等基准测试工具以高度并行的方式运行，并且会消耗大量 CPU。运行 OLTP 基准测试时，客户端机器不得成为瓶颈。

除非另有说明，否则本文档中的说明会使用配备 128 GB 磁盘的 E2-standard-32 机器作为 OLTP 基准测试的客户端，以便在配备 128 GB RAM 的 16 个 vCPU 机器上驱动 AlloyDB 实例。您必须在 AlloyDB 主实例所在的区域中创建客户端计算机。

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

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

    转到“虚拟机实例”

  2. 选择包含您要连接到的 AlloyDB 实例的项目。
  3. 点击创建实例。
  4. 点击机器配置部分。
  5. 输入实例的名称。
  6. 配置您要在其中创建实例的可用区。可用区必须与 AlloyDB 主实例的可用区相同。
  7. 选择机器类型 e2-standard-32。
  8. 保留操作系统和存储空间部分中的默认值。
  9. 点击 Networking（网络）部分，然后将 Network interfaces（网络接口）设置为为 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 文件：

    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. 修改生成的 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 基准测试结果来评估不同数据库系统和硬件配置的性能。

如需运行 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 机器（包含 NUM_WAREHOUSE=3200 和 NUM_USERS=256）上，如果 TPC-C 数据库有 30% 缓存，则您会发现 AlloyDB TPM 累计为 582,385，而 tpm-C（每分钟新订单数）为 252,970。

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

在 16 个 vCPU 机器（具有 NUM_WAREHOUSE=576 和 NUM_USERS=256）上运行的 100% 缓存 TPC-C 数据库中，您观察到 428,316 tpm-C（每分钟新订单数），累计 AlloyDB TPM 为 974,264。

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

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 Overview（概览）页面中观察到，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（Transaction Processing Performance Council Benchmark 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%

运行“仅插入索引”基准测试

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

仅索引插入基准用于衡量将数据插入数据库表的性能，重点关注索引对写入操作的影响。通过此基准测试，您可以了解在有索引和无索引的情况下，向表中添加新行的速度，从而突出显示插入期间索引维护可能导致的速度下降。

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

设置 AlloyDB 和客户端机器

如需设置基础架构以运行“仅索引插入”基准测试，请按以下步骤操作：

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

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

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

  4. 执行基准测试清理。

运行“仅插入索引”基准测试

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

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

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

    export PGHOST=<private_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 文件中验证上一个命令的输出。在此基准测试期间，您应该会看到每秒大约 52, 000 笔交易，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 实例上运行“仅选择”基准测试

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

运行“仅选择”基准测试有助于您实现以下目标：

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

  • 可伸缩性：仅选择基准测试可帮助您测试 AlloyDB 从 2 vCPU 到 AlloyDB 提供的最大 vCPU 配置的可伸缩性。

设置 AlloyDB 和客户端机器

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

运行“仅选择”基准测试

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

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

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

    export PGHOST=<private_ip>

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

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. 初始化 pgbench 数据库。以下命令会使用大约 220 GB 的真实数据初始化 pgbench 数据库。您可以使用 --scale=15000 来衡量完全缓存的“仅选择”基准测试。

    运行以下命令：

    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。这最后一步基准测试需要超过 1 小时才能完成。

    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 文件以获取最终结果。

分析基准测试结果

在此基准测试期间，您应该会观察到每秒约 467, 000 笔事务，以及大约 95% 的 CPU 利用率，如以下示例输出所示。

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
16 个 vCPU 30% 缓存 3200 256 252,970 582,385 9,706
16 个 vCPU 100% 缓存 576 256 428,316 974,264 16,238
64 个 vCPU 30% 缓存 12800 1024 589,598 1,371,160 22,853
64 个 vCPU 100% 缓存 2304 1024 716,138 1,665,438 27,757

pgbench 性能摘要

AlloyDB 机器类型 pgbench 工作负载场景 缩放比例 TPS CPU 使用率
16 个 vCPU 类似于 TPC-B，完全缓存 4000 20,359 96%
16 个 vCPU 类似于 TPC-B，部分缓存 50000 14,060 94%
16 个 vCPU 仅索引插入 25000 51,742 88%
64 个 vCPU 最大吞吐量（仅限选择） 15000 467,583 95%

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

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

准备工作

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

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

    Go to project selector

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

  4. Install the Google Cloud CLI.

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

    gcloud init

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

    Go to project selector

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

  8. Install the Google Cloud CLI.

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

    gcloud init
  10. 确保您的用户账号具有 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. 如果您创建了新的客户端机器，请设置基准测试驱动程序机器。否则，请按照本指南中针对您要运行的基准测试的说明操作。

后续步骤