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

En este documento, se describe cómo configurar AlloyDB para PostgreSQL y una máquina cliente para comparar el rendimiento de AlloyDB con TPC-C, una especificación de comparativa de OLTP. En este documento, también se describe cómo ejecutar situaciones personalizadas de OLTP con gran cantidad de operaciones de lectura y escritura, como Index Insert Only y Select Only.

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 de las instrucciones de comparativas.

Funciones de carga de trabajo de AlloyDB

AlloyDB proporciona confiabilidad, escalabilidad y rendimiento de nivel empresarial adecuados para todas las empresas y cargas de trabajo críticas. 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 la inteligencia artificial y el 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 las comparativas, lo que incluye configurar la configuración 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 de configuración optimizados para cada tipo de máquina. AlloyDB no requiere que configures marcas a nivel de la base de datos para lograr un alto rendimiento de OLTP. En su lugar, AlloyDB tiene un alto rendimiento de OLTP integrado.

Nota: La precisión de los resultados puede variar según varios factores, como el tipo de instancia de AlloyDB, el tipo de máquina cliente que ejecuta 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 y métricas de rendimiento detalladas. HammerDB admite la personalización de 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 comparativa 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.
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 bases 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 estadísticas 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

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.

   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

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.

   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

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

6. Habilita las APIs 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 reside en el mismo proyecto de Google Cloud que AlloyDB.

      Se requieren las APIs de Compute Engine y Cloud Resource Manager 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 de clúster, ingresa un nombre para tu clúster.

4. En Disponibilidad zonal, selecciona Varias 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 PostgreSQL 15.

7. Anota 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 la potencia de procesamiento adecuada. Las herramientas de comparativas, como HammerDB y pgbench, se ejecutan de manera 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, las instrucciones de este documento usan una máquina E2-standard-32 con un disco de 128 GB como cliente para las comparativas de OLTP para ejecutar una instancia de AlloyDB en una máquina de 16 vCPU 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 Debian Linux 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 TPC-C en una instancia principal de AlloyDB con 16 CPU 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 deseas 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 de e2-standard-32.
8. Conserva los valores predeterminados en la sección SO y almacenamiento.
9. Haz clic en la sección Red y establece Interfaces de red en la red de VPC configurada para el acceso de servicios privados a AlloyDB.
   Si Interfaces de red no está configurada en la red de VPC configurada para el acceso a servicios privados, expándela y, luego, establece 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 Advanced.
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 del controlador de comparativas

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

Para configurar la máquina del controlador 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 psql y, luego, asegúrate de poder 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. Ejecuta los siguientes comandos para instalar el controlador HammerDB-4.6 para la comparativa de TPC-C:

   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. Ejecuta los siguientes comandos para instalar el controlador pgbench para TPC-B y otras comparativas de OLTP:

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

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

Cómo realizar una limpieza de comparativas

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

La limpieza de comparativas 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 hardware, software o configuración.

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

1. Borra los datos de comparativas anteriores o la base de datos de comparativas. Para descartar la base de datos de comparativas anterior, usa el siguiente comando 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 Cómo conectarse 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 comparativas que incluye una implementación de comparativas 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 proveedores mayoristas.

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 adaptación de los parámetros de comparativa, lo que permite a los usuarios 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.

Situaciones de evaluación del rendimiento

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

• Modo almacenado en caché parcialmente (~30%): En este modo, se genera una base de datos 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 completamente (100%) almacenado en caché: En este modo, la base de datos 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é del búfer.

  Dado que las transacciones de TPC-C realizan operaciones de E/S mínimas (porque las operaciones de lectura 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 en caché de forma parcial. 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 consecutiva, realiza una limpieza de comparativas.

3. Ejecuta el siguiente comando para abrir hammerdb/HammerDB-4.6 directory:

   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:

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

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

6. Opcional: Para probar el modo almacenado en caché parcialmente (~30%), cambia NUM_WAREHOUSE a 3200 en el archivo setup.env. Para obtener más información, consulta Situaciones de evaluación del rendimiento.

7. Opcional: Para probar el modo completamente almacenado en caché (100%), cambia NUM_WAREHOUSE a 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 propagar 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 completa 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.

Después de completar el paso de carga, la base de datos se encuentra en un estado coherente con un conjunto definido de datos iniciales, listo para usarse en la prueba de comparativa TPC-C.

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

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

   cd hammerdb/HammerDB-4.6

2. Copia el siguiente contenido y 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. Una vez 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 almacenada en caché del 30% (con 3200 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 tpcc sea de alrededor de 55 GB.

Ejecuta la comparativa de TPC-C

Ya está todo listo para ejecutar la prueba de rendimiento 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 comercial típico, incluida 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 el sistema de bases de datos a condiciones realistas y proporcionar una forma estándar de medir el rendimiento que puedes comparar en diferentes sistemas de bases de datos. Los proveedores y los usuarios suelen usar los resultados de la comparativa TPC-C para evaluar el rendimiento de diferentes sistemas de bases de datos y configuraciones de hardware.

Nota: La siguiente secuencia de comandos ejecuta la comparativa 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 comparativas:

   cd hammerdb/HammerDB-4.6

2. Copia el siguiente contenido y 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. Cuando finalice la secuencia de comandos, podrás analizar los resultados.

Analiza los resultados de las comparativas

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 bases 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 transacciones más importantes de 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 definidos en la comparativa de TPC-C, como el pago, la entrega y el estado del pedido.

  El TPM es la métrica de rendimiento principal de la comparativa TPC-C, ya que proporciona una medición general de la capacidad del sistema para controlar una carga de trabajo realista. El 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 venta minorista.

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

Para extraer los números 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 el 30% de la base de datos TPC-C almacenada en caché en una máquina de 16 vCPU (con NUM_WAREHOUSE=3200 y NUM_USERS=256), observas 252,970 tpm-C (pedidos nuevos por minuto) de un TPM acumulado de 582,385 de AlloyDB.

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

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

Para extraer los números 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 las comparativas de rendimiento de una máquina con 16 vCPU:

Situación de TPC-C	NUM_WAREHOUSE	NUM_USERS	NOPM	TPM acumulativo
30% almacenado en caché	3200	256	252,970	582,385
100% 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 bases de datos, usa las herramientas de supervisión de AlloyDB para observar métricas importantes del sistema, como el uso de la CPU, el uso de la 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 la utilización 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 de 64 vCPU

Para ejecutar una comparativa de TPC-C en una instancia de AlloyDB de 64 vCPU, debes seguir los mismos pasos de configuración que en Cómo ejecutar una comparativa de TPC-C, pero usar diferentes tipos de máquinas.

Configura AlloyDB y la máquina cliente

1. Crea un clúster y una instancia de AlloyDB, y reemplaza 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 consecutiva, realiza una limpieza de comparativas.

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

   • Establece PGHOST en la IP privada de tu nueva instancia de AlloyDB de 64 vCPU.
   • Para la situación de TPC-C almacenada en caché del 30%, establece NUM_WAREHOUSE=12800 y NUM_USERS=1024.
   • Para la situación de TPC-C almacenada en caché al 100%, 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 las comparativas

En la siguiente tabla, se resumen los resultados de rendimiento de las comparativas en una máquina con 64 vCPU:

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

Ejecuta una comparativa de TPC-B de pgbench

TPC-B (comparativa B del Concejo del Rendimiento de Procesamiento de Transacciones) es uno de los modos de comparativas disponibles en pgbench, una herramienta de comparativas para PostgreSQL. El TPC-B simula una situación bancaria en la que varios cajeros ejecutan transacciones en las cuentas de los 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 bases de datos simulando una combinación de estas transacciones y midiendo la cantidad de transacciones por segundo que puede controlar el sistema.

El modo TPC-B en pgbench genera una base de datos sintética y simula una combinación de transacciones que se asemeja a la carga de trabajo de TPC-B, pero no está certificado oficialmente por la organización 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 afirmar 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 almacenada en caché parcialmente

En esta situación, configuras e inicializas una base de datos grande (de aproximadamente 650 GB de tamaño) con --scale= 50000. Tener una base de datos grande que no cabe en la memoria y que 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 causa una E/S significativa en el disco puede subrayar la importancia del diseño de la base de datos y la optimización de consultas. Una base de datos grande también puede exponer problemas de rendimiento relacionados con la E/S de disco, como accesos al disco lentos o 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, configuras e inicializas una base de datos de aproximadamente 60 GB de tamaño con --scale=4000 para que resida en el grupo de almacenamiento en búfer. Es importante realizar comparativas de una base de datos residente en memoria porque te permite evaluar el rendimiento máximo del sistema de bases 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 la CPU o los problemas de bloqueo, que pueden no ser evidentes cuando se comparan bases de datos que dependen de la E/S de disco.

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

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

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

2. Aprovisiona la máquina cliente y reemplaza 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 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 del 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 con valores adecuados para la configuración de tu entorno.

   • PRIVATE_IP: 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 (almacenados en caché por completo o parcialmente). En los ejemplos de esta guía, se usan valores SCALE_FACTOR y NUM_CLIENT correspondientes al tipo de máquina n2-highmem-16.

   	En caché por completo		En caché de forma parcial
   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	16000	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. Ejecuta los siguientes comandos para inicializar y cargar la base de datos de pgbench. Este paso garantiza que el conjunto de datos de comparativas se cree y se propague con datos realistas, lo que te permite simular con precisión una carga de trabajo TPC-B en la base de datos 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 en caché parcialmente tarda aproximadamente 6 horas en cargarse.
   • La base de datos almacenada en caché por completo tarda aproximadamente 45 minutos en cargarse.

6. Opcional: Realiza una verificación de precisión de carga. Para ello, asegúrate 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 precisión 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 pgbench:

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

   2. Ejecuta el siguiente comando SQL:

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

   3. 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 de un sistema de contabilidad financiera mediante la ejecución de 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 las comparativas

Verifica el resultado del comando anterior en el archivo ~/results/alloydb/pgbench/pgbench.run.out. El número de TPS debería ser cercano a los números que se muestran en la base de datos almacenada en caché por completo y en los casos de la base de datos almacenada en caché de forma parcial.

Resultados con una base de datos completamente almacenada en caché

El resultado del último comando en Ejecuta la comparativa 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 bases de datos, puedes supervisar las métricas del sistema, como el uso de la CPU, el uso de la 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 parcialmente almacenada en caché

El resultado del último comando en Ejecuta la comparativa 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 pgbench TPC-B

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

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

Ejecuta una comparativa de solo inserción de índices

La comparativa de solo inserción de índices es una situación altamente simultánea y con mucho procesamiento de escritura 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 índices 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 la rapidez con la que se pueden agregar filas nuevas a una tabla con y sin índices, lo que destaca la posible ralentización causada por el mantenimiento del índice 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 muchas operaciones de escritura, AlloyDB ofrece innovaciones arquitectónicas, como una capa de caché en niveles para ayudar con las operaciones de lectura y una tecnología de motor de almacenamiento distribuida y altamente escalable para las operaciones de escritura.

Configura AlloyDB y la máquina cliente

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

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

2. Aprovisiona la máquina cliente y reemplaza 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 solo inserción de índices

1. Conéctate a la máquina del 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 cliente. Luego, todo lo que debes 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 pgbench con el siguiente ejemplo. Si la base de datos ya existe, elimínala 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 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 las comparativas

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 utilización de la CPU de alrededor del 88% durante esta prueba de comparativa, como se muestra en el siguiente resultado de ejemplo.

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 vCPU

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 punto que son el tipo de consulta SELECT más rápido y eficiente, ya que implican acceder a una sola fila de datos directamente desde las estructuras de índice.

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

• Lograr la máxima capacidad de procesamiento: Dado que las búsquedas de punto en un índice son la forma más eficiente de consultas en un sistema de bases de datos, puedes medir la máxima capacidad de procesamiento posible que puede alcanzar AlloyDB.

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

Configura AlloyDB y la máquina cliente

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

Ejecuta la comparativa de Solo selección

1. Conéctate a la máquina del 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 cliente. Luego, todo lo que debes 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 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. El siguiente comando inicializa la base de datos de pgbench con aproximadamente 220 GB de datos realistas. Usa --scale=15000 para la comparativa de Solo selección almacenada en caché.

   Ejecuta el siguiente comando:

   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 último paso 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 las comparativas

Deberías observar aproximadamente 467,000 transacciones por segundo y una tasa de utilización de la CPU de alrededor del 95% durante esta prueba de 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 según las pruebas realizadas en este documento.

Resumen del rendimiento de TPC-C de HammerDB

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	Convertido a TPS
16vCPU	30% almacenado en caché	3200	256	252,970	582,385	9,706
16vCPU	100% en caché	576	256	428,316	974,264	16,238
64 CPU virtuales	30% en caché	12800	1024	589,598	1,371,160	22,853
64 CPU virtuales	100% 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
16vCPU	Similar a TPC-B, completamente almacenado en caché	4000	20,359	96%
16vCPU	Similar a TPC-B, almacenado en caché de forma parcial	50,000	14,060	El 94%
16vCPU	Solo inserciones de índice	25000	51,742	88%
64 CPU virtuales	Capacidad de procesamiento máxima (solo para la opción Seleccionar)	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 con 16 vCPU para el 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 elegir el SKU de 16 vCPU, habilitar la alta disponibilidad (HA) y realizar la preconfiguración con almacenamiento.

Antes de comenzar

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.

   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

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.

   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

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. 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 reemplaza 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 de alta memoria con 16 CPU 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, 1500 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. Usas 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 las comparativas 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 encontraban colocalizadas en la misma zona que la instancia principal y cuando eran lo suficientemente grandes como para llevar el servidor a su máxima capacidad.

3. Si creaste una máquina cliente nueva, configura la máquina del 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.