Cómo realizar comparativas del rendimiento de OLTP en AlloyDB para PostgreSQL

Para evaluar la capacidad de procesamiento y la latencia de tus cargas de trabajo transaccionales en AlloyDB para PostgreSQL, puedes configurar AlloyDB y una máquina cliente para comparar el rendimiento del procesamiento de transacciones en línea (OLTP) con TPC-C, una especificación de comparativas de OLTP estándar de la industria. También puedes ejecutar situaciones de OLTP personalizadas con uso intensivo de lectura y escritura, como Solo inserción de índice y Solo selección.

Las instrucciones de este documento se basan en una configuración específica de AlloyDB y la máquina cliente. Usa los valores proporcionados para cada paso en las instrucciones de comparativas.

Capacidades de carga de trabajo de AlloyDB

AlloyDB proporciona confiabilidad, escalabilidad y rendimiento de nivel empresarial adecuados para todas las empresas y cargas de trabajo esenciales. AlloyDB proporciona los siguientes componentes y funciones que permiten un alto rendimiento para tus cargas de trabajo transaccionales (OLTP), analíticas (OLAP) e híbridas (HTAP):

• Administración de registros y transacciones
• Administración dinámica de la memoria
• Integración de inteligencia artificial y aprendizaje automático
• Motor de columnas integrado
• Una caché de varios niveles
• Almacenamiento distribuido y escalable

Los sistemas de bases de datos relacionales suelen requerir que un administrador de bases de datos optimice la base de datos para la comparativa, lo que incluye configurar los parámetros del registro de transacciones, establecer los tamaños correctos del grupo de búferes y modificar otros parámetros o marcas y características de la base de datos. Estos parámetros de configuración varían según el tamaño y el tipo de instancia.

AlloyDB viene preconfigurado con parámetros optimizados para cada tipo de máquina. AlloyDB no requiere que ajustes las marcas a nivel de la base de datos para lograr un alto rendimiento de OLTP; en cambio, AlloyDB tiene un alto rendimiento de OLTP integrado.

Nota: La exactitud de los resultados puede variar según varios factores, como el tipo de instancia de AlloyDB, el tipo de máquina cliente que impulsa la comparativa, la región, la zona y el ancho de banda de la red en el momento de la prueba.

Tipos de comparativas admitidos

En este documento, se muestra cómo ejecutar comparativas de OLTP con las siguientes herramientas:

Controladores de comparativas de OLTP	Casos de uso
HammerDB	HammerDB mide el rendimiento del sistema en términos de transacciones por minuto (TPM) y genera informes que incluyen estadísticas detalladas y métricas de rendimiento. HammerDB admite la personalización de los parámetros de comparativas, lo que te permite ajustar el tamaño de la base de datos, la cantidad de almacenes y otras características de la carga de trabajo para simular diferentes situaciones. HammerDB incluye una implementación de la comparativa de TPC-C para evaluar el rendimiento de los sistemas OLTP. La implementación de TPC-C de HammerDB te permite simular una carga de trabajo similar a la comparativa de TPC-C, incluida una combinación de transacciones que imitan el comportamiento de un entorno de proveedor mayorista.
pgbench	pgbench es una herramienta de comparativas que se incluye con PostgreSQL. pgbench te permite simular cargas de trabajo de transacciones, como insertar, actualizar, seleccionar datos y medir el rendimiento del sistema de base de datos en transacciones por segundo (TPS). Cuando usas pgbench, puedes personalizar el tamaño de la base de datos, la cantidad de clientes y la combinación de transacciones para emular tu carga de trabajo de producción y obtener información sobre el comportamiento del sistema en diferentes situaciones. pgbench incluye una implementación de TPC-B. La implementación de TPC-B de pgbench es similar a una comparativa de TPC-B.

Antes de comenzar

Accede a tu cuenta de Google Cloud . Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

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.

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.

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

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.

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.

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

1. Habilita las API de Cloud necesarias para crear AlloyDB para PostgreSQL y conectarte a él.

   Habilita las APIs

   1. En el paso Confirmar proyecto, haz clic en Siguiente para confirmar el nombre del proyecto en el que realizarás cambios.

   2. En el paso Habilitar APIs, haz clic en Habilitar para habilitar lo siguiente:

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

      La API de Service Networking es obligatoria si planeas configurar la conectividad de red a AlloyDB con una red de VPC que resida en el mismo proyecto de Google Cloud que AlloyDB.

      Las APIs de Compute Engine y de Resource Manager son necesarias si planeas configurar la conectividad de red a AlloyDB con una red de VPC que reside en un proyecto de Google Cloud diferente.

Configura y aprovisiona la base de datos y la máquina cliente

Para iniciar la comparativa, crea un clúster y una instancia de AlloyDB. A menos que se especifique lo contrario, la información de este documento se basa en una CPU virtual de 16 con 128 GB de RAM como instancia principal de AlloyDB.

Crea un clúster y una instancia de AlloyDB

1. Ve a la página Clústeres.

   Ir a los clústeres

2. Haz clic en Crear clúster.

3. En el campo ID del clúster, ingresa un nombre para tu clúster.

4. En Disponibilidad zonal, selecciona Múltiples zonas (con alta disponibilidad) para el tipo de clúster.

5. Selecciona la red predeterminada.

6. En el campo Versión de la base de datos, selecciona una de las siguientes opciones:

   • PostgreSQL 17

   • PostgreSQL 18

7. Toma nota de la ubicación de la zona principal y la dirección IP privada. No crees un grupo de lectura.

   Nota: Este ejercicio de comparativas se realiza sin grupos de lectura. La instancia debe ser multizonal y de alta disponibilidad.

8. Haz clic en Crear clúster.

Aprovisiona la máquina cliente

Para ejecutar comparativas de OLTP, necesitas una máquina cliente con una capacidad de procesamiento adecuada. Las herramientas de comparativas, como HammerDB y pgbench, se ejecutan de forma muy paralela y consumen mucha CPU. Una máquina cliente no debe ser un cuello de botella cuando ejecutas una comparativa de OLTP.

A menos que se especifique lo contrario, en las instrucciones de este documento, se usa una máquina E2-standard-32 con un disco de 128 GB como cliente para las comparativas de OLTP para controlar una instancia de AlloyDB en una máquina de 16 CPU virtuales con 128 GB de RAM. Debes crear la máquina cliente en la misma zona que la instancia principal de AlloyDB.

Importante: Para ejecutar la comparativa de OLTP que se describe en este documento, debes aprovisionar el cliente de Linux Debian en la misma región, zona y VPC que la instancia principal de AlloyDB. Las herramientas de comparativas acceden a la instancia de AlloyDB a través de una IP privada.

Para ejecutar la comparativa de TPC-C en una instancia principal de AlloyDB con 16 CPUs virtuales, sigue estos pasos para crear una VM de Compute Engine y aprovisionar una máquina cliente:

1. En la consola de Google Cloud , ve a la página Instancias de VM.

   Ir a Instancias de VM

2. Selecciona el proyecto que contiene la instancia de AlloyDB a la que quieres conectarte.
3. Haz clic en Crear instancia.
4. Haz clic en la sección Configuración de la máquina.
5. Ingresa un Nombre para la instancia.
6. Configura la zona en la que deseas crear la instancia. La zona debe ser la misma que la de la instancia principal de AlloyDB.
7. Selecciona un tipo de máquina e2-standard-32.
8. Conserva los valores predeterminados en la sección SO y almacenamiento.
9. Haz clic en la sección Herramientas de redes y configura las Interfaces de red en la red de VPC configurada para el acceso privado a servicios a AlloyDB.
   Si las Interfaces de red no están configuradas en la red de VPC configurada para el acceso privado a servicios, expándelas y, luego, configura Red en la red de VPC.
10. Conserva los valores predeterminados en la sección Observabilidad.
11. Haz clic en la sección Seguridad.
12. En Identidad y acceso a la API, configura Permisos de acceso como Permitir el acceso total a todas las APIs de Cloud.
13. Conserva los valores predeterminados en la sección Avanzada.
14. Haz clic en Crear.
15. Después de crear la VM, conéctate a la VM de Compute Engine que creaste con SSH.

Configura la máquina de controladores de comparativas

Después de instalar y configurar la base de datos y la máquina cliente, configura la máquina cliente que se ejecuta en Google Cloud, en la que instalas herramientas de comparativas, como HammerDB y pgbench.

Para configurar la máquina de controladores de comparativas, sigue estos pasos:

1. Conéctate a la máquina cliente con el siguiente comando gcloud compute ssh:

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

2. Instala el cliente de PostgreSQL.

   1. Usa el siguiente comando para instalar un cliente de PostgreSQL que incluya una aplicación de psql y, luego, asegúrate de que puedas conectarte.

      sudo apt-get update
      sudo apt install postgresql-client

   2. Usa el siguiente comando para asegurarte de que el cliente funcione y de que puedas conectarte a AlloyDB. Usa la dirección IP privada de tu instancia principal de AlloyDB.

      psql -h PRIVATE_IP -U postgres

3. Instala el controlador HammerDB-4.6 para la comparativa de TPC-C ejecutando los siguientes 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. Instala el controlador de pgbench para TPC-B y las comparativas de OLTP varias ejecutando los siguientes comandos:

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

   Si pgbench --version se ejecuta sin errores, significa que pgbench está instalado.

Realiza una limpieza de comparativas

Si planeas ejecutar varias comparativas de forma consecutiva, debes realizar una limpieza entre cada una para garantizar que los resultados sean precisos y confiables.

La limpieza de una comparativa garantiza que los efectos residuales de las comparativas anteriores no afecten las mediciones de rendimiento de la comparativa nueva. Las limpiezas de comparativas también ayudan a garantizar la coherencia y la repetibilidad de los resultados de las comparativas, lo que es esencial para realizar comparaciones significativas entre diferentes sistemas o identificar áreas de optimización en el hardware, el software o la configuración.

Sigue estos pasos para realizar una limpieza de comparativas antes de ejecutar otra:

1. Borra los datos o la base de datos de comparativas anteriores. Para descartar la base de datos de comparativas anterior, usa el siguiente comando de psql desde la máquina cliente:

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

   Para obtener más información sobre el uso de psql, consulta Conéctate a una base de datos.

2. Reinicia la instancia de AlloyDB. Este paso borra las cachés a nivel de la base de datos y del sistema operativo.

Ejecuta una comparativa de TPC-C

HammerDB es una herramienta de evaluación comparativa que incluye una implementación de evaluación comparativa de TPC-C para evaluar el rendimiento de los sistemas de OLTP. La implementación de TPC-C de HammerDB te permite simular una carga de trabajo similar a la comparativa de TPC-C, incluida una combinación de transacciones que imitan el comportamiento de un entorno de proveedor mayorista.

HammerDB mide el rendimiento del sistema en términos de transacciones por minuto (TPM) y genera informes que incluyen estadísticas detalladas y métricas de rendimiento. Además, HammerDB admite la personalización de los parámetros de comparativas, lo que permite que los usuarios ajusten el tamaño de la base de datos, la cantidad de almacenes y otras características de la carga de trabajo para simular diferentes situaciones.

Casos de evaluación del rendimiento

El rendimiento de la comparativa de TPC-C se evalúa con los siguientes métodos:

• Modo de almacenamiento en caché parcial (~30%): En este modo, se genera una base de datos de TPC-C grande, que solo puede caber parcialmente en la caché del búfer. Las transacciones en este modo no siempre se entregan desde la memoria y generan E/S en los subsistemas de almacenamiento subyacentes. Esta situación se aplica a las necesidades de OLTP de muchos usuarios.

• Modo de almacenamiento en caché completo (100%): En este modo, la base de datos de TPC-C se ajusta por completo en la caché del búfer. La instancia de AlloyDB usa aproximadamente el 90% de los 128 GB de RAM disponibles, incluida la caché de búfer.

  Dado que las transacciones de TPC-C realizan operaciones de E/S mínimas, ya que las lecturas se entregan principalmente desde la caché del búfer, en este modo, se espera un TPM más alto en comparación con las ejecuciones almacenadas parcialmente en caché. Esta situación se aplica a las necesidades de OLTP de los usuarios con necesidades de E/S muy bajas.

Configura la máquina cliente

1. Configura la máquina del controlador de comparativas.

2. Si ejecutas varias comparativas de forma sucesiva, realiza una limpieza de comparativas.

3. Abre el hammerdb/HammerDB-4.6 directory ejecutando el siguiente comando:

   cd hammerdb/HammerDB-4.6

   Ejecuta comandos desde este directorio para configurar la máquina cliente.

4. Crea el archivo setup.env con los siguientes comandos:

   Nota: Si usas la agrupación de conexiones administrada, cambia el número de puerto de 5432 a 6432. Aplícalas en todos los ejemplos de esta página.

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

   Nota: La cantidad de usuarios (o clientes) se establece en 256. Esta cantidad de usuarios se ajusta para proporcionar la mejor capacidad de procesamiento con una latencia aceptable en las configuraciones almacenadas en caché de forma parcial y total.

5. Edita el archivo setup.env generado reemplazando todos los valores de los parámetros destacados por los valores de los parámetros que mejor se adapten a la configuración de tu entorno.

6. Opcional: Prueba el modo de almacenamiento en caché parcial (~30%) cambiando NUM_WAREHOUSE por 3200 en el archivo setup.env. Para obtener más información, consulta Situaciones de evaluación del rendimiento.

7. Opcional: Prueba el modo de almacenamiento en caché completo (100%) cambiando NUM_WAREHOUSE por 576 en setup.env file. Para obtener más información, consulta Situaciones de evaluación del rendimiento.

Carga datos de TPC-C en la base de datos

Un paso de carga se refiere al proceso de completar la base de datos de comparativas con datos iniciales antes de ejecutar la prueba de rendimiento.

Durante el paso de carga, la base de datos se propaga con una cantidad especificada de almacenes, clientes y otras entidades según las especificaciones de TPC-C. El propósito del paso de carga es crear una carga de trabajo realista para la prueba de rendimiento y garantizar que los resultados de la prueba sean comparables en diferentes sistemas.

Una vez que se completa el paso de carga, la base de datos se encuentra en un estado coherente con un conjunto definido de datos iniciales, listos para usarse en la prueba comparativa de TPC-C.

Para cargar la base de datos de TPC-C, sigue estos pasos:

1. Cambia al directorio principal de la comparativa con el siguiente comando:

   cd hammerdb/HammerDB-4.6

2. Copia el siguiente contenido y, luego, pégalo en 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. Ejecuta el siguiente comando de carga y espera a que finalice.

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

4. Valida la carga. Después de que se complete la secuencia de comandos anterior, te recomendamos que confirmes que la carga de la base de datos se haya realizado correctamente. Para verificar el tamaño de la base de datos, ejecuta lo siguiente:

   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)
   

En una configuración de TPC-C con un 30% de almacenamiento en caché (con 3,200 almacenes), se espera que el tamaño de la base de datos tpcc sea de alrededor de 300 GB.

En la configuración de TPC-C almacenada en caché al 100% (con 576 almacenes), se espera que el tamaño de la base de datos de tpcc sea de alrededor de 55 GB.

Ejecuta la comparativa de TPC-C

Ya está todo listo para ejecutar la prueba de rendimiento de TPC-C. La comparativa de TPC-C se ejecuta con la base de datos propagada del paso de carga. La comparativa genera una serie de transacciones que simulan un entorno empresarial típico, lo que incluye la entrada de pedidos, el procesamiento de pagos y la administración de inventario. La carga de trabajo se mide en transacciones por minuto (TPM), que representa la cantidad de transacciones comerciales completas que el sistema puede controlar en un minuto.

El paso de ejecución está diseñado para someter al sistema de base de datos a condiciones realistas y proporcionar una forma estándar de medir el rendimiento que puedas comparar entre diferentes sistemas de bases de datos. Los proveedores y los usuarios suelen usar los resultados de la comparativa de TPC-C para evaluar el rendimiento de diferentes sistemas de bases de datos y parámetros de configuración de hardware.

Nota: La siguiente secuencia de comandos ejecuta la comparativa de TPC-C durante aproximadamente 1 hora después de unos 10 minutos de preparación.

Para ejecutar la comparativa de TPC-C, sigue estos pasos:

1. Cambia al directorio principal de la comparativa:

   cd hammerdb/HammerDB-4.6

2. Copia el siguiente contenido y, luego, pégalo en 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. Ejecuta la secuencia de comandos con los siguientes comandos:

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

4. Espera a que finalice la secuencia de comandos run-tpcc.sh. La secuencia de comandos tarda aproximadamente 1 hora y 10 minutos en completarse. Una vez que finalice la secuencia de comandos, podrás analizar los resultados.

Analiza los resultados de la comparativa

En las comparativas de TPC-C, los pedidos nuevos por minuto (NOPM) y las transacciones por minuto (TPM) son métricas de rendimiento que se usan para medir el rendimiento de un sistema de base de datos.

• NOPM: Mide la cantidad de transacciones de pedidos nuevos que el sistema puede controlar en un minuto. La transacción de pedido nuevo es una de las más importantes en la comparativa de TPC-C y consiste en crear un pedido nuevo para un cliente.

• TPM: Mide la cantidad total de transacciones comerciales completadas que el sistema puede controlar en un minuto. Las transacciones incluyen transacciones de pedidos nuevos, así como otros tipos de transacciones definidas en la comparativa de TPC-C, como el pago, la entrega y el estado del pedido.

  TPM es la métrica de rendimiento principal para la comparativa de TPC-C, ya que proporciona una medición general de la capacidad del sistema para controlar una carga de trabajo realista. La NOPM puede ser una métrica útil para los sistemas que se enfocan en procesar pedidos nuevos, como los sistemas de comercio electrónico o de venta minorista.

Visualiza los resultados con un 30% de la base de datos de TPC-C almacenada en caché en una máquina con 16 CPUs virtuales

Para extraer las cifras de rendimiento de esta situación, usa el siguiente comando:

grep NOPM results/run-tpcc.out

El siguiente es el resultado esperado:

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

Con un 30% de la base de datos de TPC-C almacenada en caché en una máquina de 16 CPUs virtuales (con NUM_WAREHOUSE=3200 y NUM_USERS=256), se observan 252,970 tpm-C (nuevos pedidos por minuto) de un total acumulado de 582,385 TPM de AlloyDB.

Visualiza los resultados con la base de datos de TPC-C almacenada en caché al 100% en una máquina con 16 CPUs virtuales

En una base de datos TPC-C almacenada en caché al 100% en una máquina con 16 CPU virtuales (con NUM_WAREHOUSE=576 y NUM_USERS=256), se observan 428,316 tpm-C (nuevos pedidos por minuto) de un TPM de AlloyDB acumulativo de 974,264.

Para extraer las cifras de rendimiento de esta situación, usa el siguiente comando:

grep NOPM results/tpcc-run.out

El siguiente es el resultado esperado:

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

Resumen de los resultados de rendimiento en una máquina con 16 CPU virtuales

En la siguiente tabla, se resumen los resultados de rendimiento de las comparativas para una máquina de 16 CPU virtuales:

Situación de TPC-C	NUM_WAREHOUSE	NUM_USERS	NOPM	TPM acumulativo
30% almacenado en caché	3200	256	252,970	582,385
100% almacenado en caché	576	256	428,316	974,264

Observa las métricas de rendimiento de la base de datos

Para comprender mejor el comportamiento de tu sistema de base de datos, usa las herramientas de supervisión de AlloyDB para observar las métricas importantes del sistema, como el uso de CPU, el uso de memoria y las transacciones por segundo. Para obtener más información, consulta Supervisa el rendimiento de las instancias.

Por ejemplo, después de ejecutar esta comparativa, puedes observar en la página Descripción general de AlloyDB en la consola de Google Cloud que el uso promedio de la CPU para la ejecución de TPC-C almacenada en caché al 100% es de casi el 90%.

Ejecuta una comparativa de TPC-C en una instancia de AlloyDB con 64 CPUs virtuales

Para ejecutar una comparativa de TPC-C en una instancia de AlloyDB de 64 CPUs virtuales, sigue los mismos pasos de configuración que en Ejecuta una comparativa de TPC-C, pero usa diferentes tipos de máquinas.

Configura AlloyDB y la máquina cliente

1. Crea un clúster y una instancia de AlloyDB, sustituyendo 64 vCPU, 512GB como el tipo de máquina.

2. Aprovisiona la máquina cliente y sustituye n2-standard-64 como el tipo de máquina.

3. Configura la máquina del controlador de comparativas.

Ejecuta las comparativas

1. Si ejecutas varias comparativas de forma sucesiva, realiza una limpieza de comparativas.

2. Configura la máquina cliente y sustituye los siguientes valores:

   • Establece PGHOST en la IP privada de tu nueva instancia de AlloyDB con 64 CPUs virtuales.
   • Para la situación de TPC-C con un 30% de almacenamiento en caché, establece NUM_WAREHOUSE=12800 y NUM_USERS=1024.
   • Para la situación de TPC-C 100% almacenada en caché, establece NUM_WAREHOUSE=2304 y NUM_USERS=1024.

3. Configura y carga una base de datos de TPC-C. Para acelerar la carga, cambia el valor de pg_num_vu a 64 en build-tpcc.sh como diset tpcc pg_num_vu 64.

4. Ejecuta la comparativa de TPC-C.

Analiza los resultados de la comparativa

En la siguiente tabla, se resumen los resultados de rendimiento de la comparativa en una máquina con 64 CPUs virtuales:

Modo de comparativas	NUM_WAREHOUSE	NUM_USERS	NOPM	TPM acumulativo
30% almacenado en caché	12800	1024	589,598	1,371,160
100% almacenado en caché	2304	1024	716,138	1,665,438

Ejecuta una comparativa de TPC-B de pgbench

TPC-B (Transaction Processing Performance Council Benchmark B) es uno de los modos de comparativas disponibles en pgbench, una herramienta de comparativas para PostgreSQL. TPC-B simula una situación bancaria en la que varios cajeros ejecutan transacciones en cuentas de clientes. La carga de trabajo consta de los siguientes tipos de transacciones:

• Depósitos
• Retiros
• Consultas de saldo

La comparativa mide el rendimiento del sistema de base de datos simulando una combinación de estas transacciones y midiendo la cantidad de transacciones por segundo que el sistema puede controlar.

El modo TPC-B en pgbench genera una base de datos sintética y simula una mezcla de transacciones que se asemeja a la carga de trabajo de TPC-B, pero no está certificada oficialmente por la organización de TPC. Por lo tanto, si bien el modo TPC-B en pgbench proporciona una aproximación útil del rendimiento de TPC-B, no lo uses para reclamar el cumplimiento de los estándares de TPC-B.

Situaciones para medir el rendimiento

En esta sección, se describe cómo medir el rendimiento de TPC-B en los siguientes modos críticos. El único parámetro que es diferente en estos modos es el valor del parámetro SCALE_FACTOR.

Situación de base de datos con almacenamiento en caché parcial

En esta situación, configurarás e inicializarás una base de datos grande (de aproximadamente 650 GB) con --scale= 50000. Tener una base de datos grande que no cabe en la memoria y causa una E/S de disco significativa proporciona una representación realista de muchas cargas de trabajo de producción.

Una base de datos grande que genera una E/S de disco significativa puede destacar la importancia del diseño de la base de datos y la optimización de las consultas. Una base de datos grande también puede exponer problemas de rendimiento relacionados con la E/S de disco, como el acceso lento al disco o las consultas ineficientes, que podrían no ser evidentes en una base de datos pequeña o que reside por completo en la memoria.

Situación de base de datos completamente almacenada en caché

En esta situación, configurarás e inicializarás una base de datos de aproximadamente 60 GB con --scale=4000 para que resida en el grupo de búferes. La comparativa de una base de datos residente en la memoria es importante porque te permite evaluar el rendimiento máximo del sistema de base de datos en un entorno controlado.

Una base de datos residente en la memoria almacena todos los datos en el grupo de búferes de PostgreSQL, lo que elimina el cuello de botella de E/S que puede ocurrir cuando se accede a los datos desde el disco. Este modo puede ayudar a identificar cuellos de botella de rendimiento que no están relacionados con la E/S, como el uso de CPU o los problemas de bloqueo, que podrían no ser evidentes cuando comparas una base de datos que depende de la E/S de disco.

Configura el servidor de la base de datos y la máquina cliente

Para configurar la infraestructura y ejecutar una comparativa de TPC-B de pgbench, sigue estos pasos:

1. Crea un clúster y una instancia de AlloyDB, sustituyendo 16 vCPU, 128GB como el tipo de máquina.

2. Aprovisiona la máquina cliente y sustituye E2-standard-16 (minimum) como el tipo de máquina.

3. Configura la máquina del controlador de comparativas.

4. Realiza una limpieza de comparativas.

Ejecuta la comparativa de TPC-B de pgbench

Importante: Te recomendamos que ejecutes la comparativa durante un período más largo, ya que la capacidad de procesamiento es menor en los primeros segundos y lleva tiempo alcanzar un estado estable.

1. Conéctate a la máquina cliente con el siguiente comando de Google Cloud CLI:

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

2. Crea el archivo 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. Edita el archivo setup.env generado y reemplaza el siguiente valor del parámetro por valores que sean adecuados para la configuración de tu entorno.

   • PRIVATE_IP: Es la IP privada de tu instancia de AlloyDB.

   Usa la siguiente tabla para elegir los valores de <scale_factor> y <num_clients>. Estos valores deben escalar con el tipo de máquina y el tamaño de la base de datos (almacenada en caché por completo o de forma parcial). En los ejemplos de esta guía, se usan los valores SCALE_FACTOR y NUM_CLIENT correspondientes al tipo de máquina n2-highmem-16.

   	Almacenamiento en caché completo		Almacenamiento parcial en caché
   Tipo de máquina	SCALE_FACTOR	NUM_CLIENTS	SCALE_FACTOR	NUM_CLIENTS
   n2-highmem-2	500	48	6250	32
   n2-highmem-4	1000	96	12500	64
   n2-highmem-8	2000	192	25000	128
   n2-highmem-16	4000	384	50,000	256
   n2-highmem-32	8000	768	100000	512
   n2-highmem-64	16,000	1,536	200000	1024

4. Crea una base de datos de pgbench.

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

5. Inicializa y carga la base de datos de pgbench ejecutando los siguientes comandos. Este paso garantiza que el conjunto de datos de comparativas se cree y se complete con datos realistas, lo que te permite simular con precisión una carga de trabajo de TPC-B en la base de datos de 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
   

   Tiempos de carga esperados:

   • La base de datos almacenada parcialmente en caché tarda aproximadamente 6 horas en cargarse.
   • La base de datos completamente almacenada en caché tarda aproximadamente 45 minutos en cargarse.

6. Opcional: Realiza una verificación de precisión de carga asegurándote de que el contenido del archivo /tmp/pgbench-tpcb-partially-cached-db-init.out sea similar al siguiente:

   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 aún más la exactitud de la carga, ejecuta el siguiente comando de PostgreSQL que mide el tamaño de todas las tablas de pgbench:

   1. Conéctate a la base de datos de pgbench:

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

   2. Ejecuta el siguiente comando de 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. Compara el resultado del comando anterior con el resultado que obtuviste para la ejecución de la base de datos almacenada en caché de forma parcial (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. Ejecuta los siguientes comandos para simular una carga de trabajo del sistema de contabilidad financiera ejecutando una serie de transacciones que involucran depósitos, transferencias y pagos, lo que te permite medir el rendimiento de la base de datos con una carga de trabajo 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
   

Analiza los resultados de la comparativa

Verifica el resultado del comando anterior en el archivo ~/results/alloydb/pgbench/pgbench.run.out. La cantidad de TPS debe ser cercana a las que se muestran en las situaciones de base de datos completamente almacenada en caché y parcialmente almacenada en caché.

Resultados con una base de datos completamente almacenada en caché

El resultado del último comando en Ejecuta la comparativa de TPC-B de pgbench debería ser similar al siguiente, en el 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 comprender mejor el comportamiento del sistema de base de datos, puedes supervisar las métricas del sistema, como el uso de CPU, el uso de memoria y las transacciones por segundo, con la consola de Google Cloud . Para obtener más información, consulta Supervisa instancias.

Resultados con una base de datos almacenada parcialmente en caché

El resultado del último comando en Ejecuta la comparativa de TPC-B de pgbench debería ser similar al siguiente, en el 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)

Resumen de los resultados de rendimiento de una comparativa de TPC-B de pgbench

En la siguiente tabla, se resumen los resultados de rendimiento de una comparativa de TPC-B de pgbench:

Situación de TPC-B	SCALE_FACTOR	TPS	Uso de CPU (%)
Almacenamiento en caché parcial	50,000	17,460	96%
Almacenamiento en caché completo	4000	21,750	94%

Ejecuta una comparativa de solo inserción de índice

La comparativa de inserción de índices es una situación de alta simultaneidad y de escritura intensiva que se personaliza en esta sección para mostrar los beneficios de rendimiento de AlloyDB para la mayoría de las aplicaciones de OLTP. Para ejecutar esta comparativa, crea varios índices en la tabla pgbench_history y, luego, realiza operaciones INSERT de forma repetida en la tabla pgbench_history desde varias conexiones de cliente.

Las comparativas de inserción solo de índice miden el rendimiento de la inserción de datos en una tabla de base de datos, enfocándose específicamente en el impacto de los índices en la operación de escritura. Esta comparativa te permite comprender con qué rapidez se pueden agregar filas nuevas a una tabla con y sin índices, lo que destaca la posible ralentización que causa el mantenimiento de índices durante las inserciones.

AlloyDB mejora el rendimiento de escritura de PostgreSQL, lo que también mejora las cargas de trabajo de OLTP. Para mejorar el rendimiento de las situaciones de OLTP con uso intensivo de escritura, AlloyDB ofrece innovaciones de arquitectura, incluida una capa de caché por niveles para ayudar con las lecturas y una tecnología de motor de almacenamiento distribuido y altamente escalable para las escrituras.

Configura AlloyDB y la máquina cliente

Para configurar la infraestructura y ejecutar una comparativa de inserción solo de índice, sigue estos pasos:

1. Crea un clúster y una instancia de AlloyDB, sustituyendo 16 vCPU and 128 GB RAM como el tipo de máquina.

2. Aprovisiona la máquina cliente y sustituye E2-standard-16 (minimum) como el tipo de máquina.

3. Configura la máquina del controlador de comparativas.

4. Realiza una limpieza de las comparativas.

Ejecuta la comparativa de inserción de solo índice

1. Conéctate a la máquina cliente con el siguiente comando de ejemplo:

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

2. Ejecuta el siguiente comando para configurar el entorno:

   export PGHOST=<private_ip>
   

   Importante: Ejecuta todos los comandos restantes de este procedimiento desde la misma terminal del cliente. Luego, todo lo que necesitas hacer es exportar la variable de entorno PGHOST una vez y asignarla a la IP privada de tu instancia de AlloyDB. Si conectas varias terminales a la máquina cliente, exporta la siguiente variable de entorno en todas las terminales.

3. Crea una base de datos de pgbench con el siguiente ejemplo. Si la base de datos ya existe, bórrala y vuelve a crearla.

   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. Inicializa y carga la base de datos de pgbench para asegurarte de que el conjunto de datos de comparativas se cree y se complete con datos realistas. Edita los parámetros destacados y, luego, ejecuta el siguiente 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. Verifica que el resultado del comando anterior sea similar al siguiente:

   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. Crea la secuencia de comandos index-init.sql con los siguientes 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. Ejecuta la secuencia de comandos index-init.sql:

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

8. Opcional: Valida el esquema de la base de datos y la carga 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)
   

   Después de la carga, se espera que el tamaño de la base de datos sea de alrededor 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. Crea la secuencia de comandos index-inserts-only.sql con los siguientes 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. Ejecuta la comparativa de pgbench con el siguiente 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

Analiza los resultados de la comparativa

Verifica el resultado del comando anterior en el archivo /tmp/pgbench-index-insert-only-run.out. Deberías ver aproximadamente 52,000 transacciones por segundo y una tasa de uso de CPU del ~88% durante esta prueba comparativa, como se muestra en el siguiente ejemplo de resultado.

scaling factor: 25000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 201785196
latency average = 4.947 ms
latency stddev = 3.488 ms
tps = 51738.604613 (including connections establishing)
tps = 51742.459757 (excluding connections establishing)

Ejecuta una comparativa de solo selección en una instancia de 64 CPUs virtuales

pgbench admite una situación integrada de solo selección que ejecuta de forma repetida consultas SELECT desde varias conexiones de cliente en una base de datos especificada. Esta comparativa se usa para medir el rendimiento de lectura de la base de datos, sin introducir la sobrecarga de las operaciones de modificación de datos, como INSERT, UPDATE o DELETE. Estas consultas SELECT son consultas de búsqueda de puntos que son el tipo de consultas SELECT más rápido y eficiente, ya que implican acceder solo a una fila de datos directamente desde las estructuras de índice.

Ejecutar una comparativa de solo selección te ayuda a lograr lo siguiente:

• Alcanza la capacidad de procesamiento máxima: Debido a que las búsquedas de puntos en un índice son la forma más eficiente de consultas en un sistema de base de datos, puedes medir la capacidad de procesamiento máxima posible que puede alcanzar AlloyDB.

• Escalabilidad: Selecciona solo las comparativas que te ayuden a probar la escalabilidad de AlloyDB desde 2 CPU virtuales hasta la configuración máxima de CPU virtuales que ofrece AlloyDB.

Configura AlloyDB y la máquina cliente

Configura AlloyDB y la máquina cliente en un tipo de máquina de 64 CPU virtuales.

Ejecuta la comparativa de solo selección

1. Conéctate a la máquina cliente con el siguiente comando de ejemplo:

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

2. Configura el entorno con el siguiente comando:

   export PGHOST=<private_ip>
   

   Importante: Ejecuta todos los comandos restantes de este procedimiento desde la misma terminal del cliente. Luego, todo lo que necesitas hacer es exportar la variable de entorno PGHOST una vez y asignarla a la IP privada de tu instancia de AlloyDB. Si conectas varias terminales a la máquina cliente, exporta la siguiente variable de entorno en todas las terminales.

3. Crea la base de datos de pgbench con el siguiente ejemplo:

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

4. Inicializa la base de datos de pgbench. Con el siguiente comando, se inicializa la base de datos de pgbench con aproximadamente 220 GB de datos realistas. Usa --scale=15000 para la comparativa de solo selección completamente almacenada en caché.

   Ejecuta el comando siguiente:

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

5. Verifica que el resultado del comando anterior sea similar al siguiente:

   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. Ejecuta pgbench. Este paso final de comparativas tarda más de una hora en completarse.

   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. Una vez que se complete la comparativa, consulta el archivo /tmp/pgbench-select-only-run.out para ver los resultados finales.

Analiza los resultados de la comparativa

Deberías observar aproximadamente 467,000 transacciones por segundo y una tasa de uso de CPU de ~95% durante esta prueba comparativa, como se muestra en el siguiente resultado de ejemplo.

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)

Resumen de los resultados de las comparativas de AlloyDB

En las siguientes tablas, se resumen los resultados de las comparativas de AlloyDB en función de las pruebas realizadas en este documento.

Resumen de rendimiento de HammerDB TPC-C

Tipo de máquina de AlloyDB	Situación de carga de trabajo de TPC-C	NUM_WAREHOUSE	NUM_USERS	Pedidos nuevos por minuto (NOPM)	TPM acumulativo	Se convirtió en TPS
16 CPU virtuales	30% almacenado en caché	3200	256	252,970	582,385	9,706
16 CPU virtuales	100% almacenado en caché	576	256	428,316	974,264	16,238
64 CPU virtuales	30% almacenado en caché	12800	1024	589,598	1,371,160	22,853
64 CPU virtuales	100% almacenado en caché	2304	1024	716,138	1,665,438	27,757

Resumen del rendimiento de pgbench

Tipo de máquina de AlloyDB	Situación de carga de trabajo de pgbench	Factor de escala	TPS	%de CPU
16 CPU virtuales	TPC-B Like, Fully Cached	4000	20,359	96%
16 CPU virtuales	TPC-B Like, Partially Cached	50,000	14,060	94%
16 CPU virtuales	Solo inserciones de índices	25000	51,742	88%
64 CPUs virtuales	Capacidad de procesamiento máxima (solo selección)	15000	467,583	95%

Ejecuta comparativas de OLTP en Cloud SQL para PostgreSQL

Puedes probar el rendimiento de OLTP equivalente en PostgreSQL en Cloud SQL para PostgreSQL en un tipo de máquina de 16 CPUs virtuales para realizar un análisis comparativo. En esta sección, se describe cómo configurar una instancia de Cloud SQL para PostgreSQL (o cualquier servidor de PostgreSQL implementado en la infraestructura que elijas) que sea comparable con la configuración de AlloyDB que se usa en esta guía para comparar el rendimiento de OLTP. En esta situación, se incluye la elección del SKU de 16 CPU virtuales, la habilitación de la alta disponibilidad (HA) y la configuración previa con almacenamiento.

Antes de comenzar

Accede a tu cuenta de Google Cloud . Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

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.

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.

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

Install the Google Cloud CLI.

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

To initialize the gcloud CLI, run the following command:

gcloud init

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

Roles required to select or create a project

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

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

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

Install the Google Cloud CLI.

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

To initialize the gcloud CLI, run the following command:

gcloud init

1. Asegúrate de tener las funciones de administrador de Cloud SQL y visualizador de Compute en tu cuenta de usuario.

   Ir a la página IAM

   Obtén más información sobre las funciones y los permisos.

Aprovisiona una instancia de Cloud SQL para PostgreSQL

1. Crea una instancia de PostgreSQL y sustituye los siguientes valores:

   • Versión de la base de datos: PostgreSQL 14
   • Elige una configuración para comenzar: Producción
   • Elige la región y la disponibilidad zonal: Selecciona us-central1 como la región.
   • Disponibilidad zonal: Varias zonas (con alta disponibilidad)
     • Zona principal: us-central1-c
     • Zona secundaria: us-central-1-f
   • Tipo de máquina: Máquina con alta capacidad de memoria, 16 CPUs virtuales y 104 GB. Esta es la máquina más cercana que ofrece Cloud SQL para PostgreSQL a la instancia de AlloyDB coincidente que creaste en la sección de comparativas de AlloyDB de este documento.
   • Capacidad de almacenamiento: Personalizada, 1,500 GB
     • Habilitar los aumentos de almacenamiento automáticos
   • Encriptación: Google-owned and Google-managed encryption key
   • Conexiones: IP privada
     • Red: default
     • IP pública: Habilitada

2. Haz clic en Crear instancia.

3. Después de crear la instancia de PostgreSQL, toma nota de la dirección IP privada. Usa la IP como PGHOST para establecer conexiones con la comparativa.

Aprovisiona la máquina cliente

1. Aprovisiona una instancia de Cloud SQL para PostgreSQL. Para ejecutar la comparativa de OLTP que elijas, necesitas una máquina cliente con una potencia de CPU significativa en la misma zona que la instancia principal de Cloud SQL para PostgreSQL en Cloud SQL.

2. Opcional: Como alternativa al paso anterior, puedes usar la misma máquina cliente que configuraste para la comparativa de AlloyDB, siempre que se cumpla lo siguiente:

   • La máquina cliente se encuentra en la misma zona que la nueva instancia principal de PostgreSQL (Cloud SQL para PostgreSQL).
   • La máquina cliente cumple con los requisitos mínimos de CPU, RAM y tamaño de disco.

   En esta guía de comparativas, reutilizaste las máquinas cliente cuando se ubicaron en la misma zona que la instancia principal y cuando eran lo suficientemente grandes como para llevar el servidor a su capacidad máxima.

3. Si creaste una máquina cliente nueva, configura la máquina de controlador de comparativas. De lo contrario, sigue las instrucciones de esta guía para la comparativa que te interesa ejecutar.

¿Qué sigue?

• Supervisa el rendimiento de las instancias de AlloyDB.