El propósito de la evaluación comparativa de una base de datos no es solo verificar la capacidad de la base de datos, sino también el comportamiento de una base de datos en particular frente a su aplicación. Diferentes hardwares brindan diferentes resultados según el plan de evaluación comparativa que establezca. Es muy importante aislar el servidor (el que se está comparando) de otros elementos, como los servidores que controlan la carga o los servidores utilizados para recopilar y almacenar métricas de rendimiento. Como parte del ejercicio de evaluación comparativa, debe obtener las características de la aplicación como a) ¿La aplicación es intensiva en lectura o escritura? o b) ¿cuál es la división de lectura/escritura (por ejemplo, 80:20)? o c) ¿Qué tamaño tiene el conjunto de datos? ¿Son los datos y la estructura representativos de la base de datos de producción real, etc.
PostgreSQL es la base de datos de código abierto más avanzada del mundo. Si algún cliente empresarial de RDBMS quiere migrar su base de datos a código abierto, entonces PostgreSQL sería la primera opción para evaluar.
Esta publicación cubre lo siguiente:
- Cómo comparar PostgreSQL
- ¿Cuáles son los factores clave de rendimiento en PostgreSQL?
- ¿Cuáles son las palancas que puede utilizar para aumentar el rendimiento?
- ¿Qué escollos de rendimiento se deben evitar?
- ¿Cuáles son los errores comunes que comete la gente?
- ¿Cómo sabe si su sistema está funcionando? ¿Qué herramientas puedes usar?
Cómo comparar PostgreSQL
La herramienta estándar para comparar PostgreSQL es pgbench. De forma predeterminada, las pruebas de pgbench se basan en TPC-B. Implica 5 comandos SELECCIONAR, INSERTAR y ACTUALIZAR por transacción. Sin embargo, según el comportamiento de su aplicación, puede escribir sus propios archivos de script. Veamos los resultados predeterminados y algunos resultados de pruebas orientados a secuencias de comandos. Vamos a utilizar la última versión de PostgreSQL para estas pruebas, que es PostgreSQL 10 en el momento de escribir este artículo. Puede instalarlo usando ClusterControl o usando las instrucciones aquí:https://www.openscg.com/bigsql/package-manager/.
Especificaciones de la máquina
Versión:RHEL 6 - 64 bits
Memoria:4GB
Procesadores:4
Almacenamiento:50G
Versión de PostgreSQL:10.0
Tamaño de la base de datos:15G
Antes de ejecutar la evaluación comparativa con la herramienta pgbench, deberá inicializarla debajo del comando:
-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE: table "pgbench_history" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.Como se muestra en los mensajes de AVISO, crea las tablas pgbench_history, pgbench_tellers, pgbench_accounts y pgbench_branches para ejecutar las transacciones para la evaluación comparativa.
Aquí hay una prueba simple con 10 clientes:
-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)Como puede ver, funcionó con 10 clientes y 10 transacciones por cliente. Le dio 739 transacciones/seg. Le dio 739 transacciones/seg. Si desea ejecutarlo durante un período de tiempo específico, puede usar la opción "-T". En general, una carrera de 15 o 30 minutos es suficiente.
A partir de ahora, hablamos sobre cómo ejecutar pgbench, sin embargo, no sobre cuáles deberían ser las opciones. Antes de comenzar la evaluación comparativa, debe obtener los detalles adecuados del equipo de aplicación en:
- ¿Qué tipo de carga de trabajo?
- ¿Cuántas sesiones simultáneas?
- ¿Cuál es el conjunto de resultados promedio de las consultas?
- ¿Cuáles son los tps (transacción por segundo) esperados?
Este es un ejemplo de cargas de trabajo de solo lectura. Puede usar la opción "-S" para usar solo SELECCIONES que se encuentran en solo lectura. Tenga en cuenta que -n es para omitir pasar la aspiradora en las mesas.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$La latencia aquí es el tiempo de transacción promedio transcurrido de cada declaración ejecutada por cada cliente. Da 52 tps con el hardware dado. Como este punto de referencia es para un entorno de solo lectura, intentemos ajustar los parámetros shared_buffers y effectiva_cache_size en el archivo postgresql.conf y verifiquemos el recuento de tps. Están en valores predeterminados en la prueba anterior, intente aumentar los valores y verifique los resultados.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)Cambiar los parámetros mejoró el rendimiento en un 30 %.
pgbench normalmente ejecuta transacciones en sus propias tablas. Si tiene una carga de trabajo de 50 % de lecturas y 50 % de escrituras (o un entorno 60:40), puede crear un archivo de secuencia de comandos con un conjunto de instrucciones para lograr la carga de trabajo esperada.
-bash-4.1$ cat /tmp/bench.sql
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
- weight: 1 (targets 50.0% of total)
- 12707 transactions (50.0% of total, tps = 42.225555)
- latency average = 914.240 ms
- latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
- weight: 1 (targets 50.0% of total)
- 12729 transactions (50.0% of total, tps = 42.298662)
- latency average = 1446.721 ms
- latency stddev = 765.933 ms¿Cuáles son los factores clave de rendimiento en PostgreSQL?
Si consideramos un entorno de producción real, se consolida con diferentes componentes a nivel de aplicación, hardware como CPU y memoria, y el sistema operativo subyacente. Instalamos PostgreSQL sobre el sistema operativo para comunicarse con otros componentes del entorno de producción. Cada entorno es diferente y el rendimiento general se degradará si no se configura correctamente. En PostgreSQL, algunas consultas se ejecutan más rápido y otras más lentamente, sin embargo, depende de la configuración que se haya establecido. El objetivo de la optimización del rendimiento de la base de datos es maximizar el rendimiento de la base de datos y minimizar las conexiones para lograr el mayor rendimiento posible. A continuación se presentan algunos factores clave de rendimiento que afectan a la base de datos:
- Carga de trabajo
- Recurso
- Optimización
- Contención
La carga de trabajo consta de trabajos por lotes, consultas dinámicas para transacciones en línea, consultas de análisis de datos que se utilizan para generar informes. La carga de trabajo puede ser diferente durante el período del día, la semana o el mes, y depende de las aplicaciones. La optimización de cada base de datos es única. Puede ser la configuración a nivel de base de datos o la optimización a nivel de consulta. Cubriremos más sobre la optimización en otras secciones de la publicación. La contención es la condición en la que dos o más componentes de la carga de trabajo intentan utilizar un único recurso de forma conflictiva. A medida que aumenta la contención, disminuye el rendimiento.
¿Qué son los consejos y mejores prácticas?
Estos son algunos consejos y prácticas recomendadas que puede seguir para evitar problemas de rendimiento:
- Puede considerar ejecutar actividades de mantenimiento como VACUUM y ANALYZE después de una gran modificación en su base de datos. Esto ayuda al planificador a idear el mejor plan para ejecutar consultas.
- Busque cualquier necesidad de indexar tablas. Hace que las consultas se ejecuten mucho más rápido, en lugar de tener que realizar exploraciones de tablas completas.
- Para hacer un recorrido de índice mucho más rápido, puede usar los comandos CREATE TABLE AS o CLUSTER para agrupar filas con valores clave similares.
- Cuando vea un problema de rendimiento, use el comando EXPLAIN para ver el plan sobre cómo el optimizador ha decidido ejecutar su consulta.
- Puede intentar cambiar los planes influyendo en el optimizador modificando los operadores de consulta. Por ejemplo, si ve un escaneo secuencial para su consulta, puede deshabilitar el escaneo secuencial usando "SET ENABLE_SEQSCAN TO OFF". No hay garantía de que el optimizador no elija ese operador si lo desactiva. El optimizador solo considera que el operador es mucho más caro. Más detalles están aquí:https://www.postgresql.org/docs/current/static/runtime-config-query.html
- También puede intentar cambiar los parámetros de costos como CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST y EFFECTIVE_CACHE_SIZE para influir en el optimizador. Más detalles están aquí:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
- Siempre filtre los datos en el servidor en lugar de en la aplicación del cliente. Minimizará el tráfico de la red y brindará un mejor rendimiento.
- Para realizar operaciones comunes, siempre se recomienda utilizar procedimientos del lado del servidor (disparadores y funciones). Los activadores o funciones del lado del servidor se analizan, planifican y optimizan la primera vez que se usan, no siempre.
¿Cuáles son los errores comunes que cometen las personas?
Uno de los errores comunes que cometen las personas es ejecutar el servidor de base de datos y la base de datos con parámetros predeterminados. La configuración predeterminada de PostgreSQL se prueba en algunos entornos; sin embargo, no todas las aplicaciones encontrarían esos valores óptimos. Por lo tanto, debe comprender el comportamiento de su aplicación y, en función de ello, establecer sus parámetros de configuración. Puede utilizar la herramienta pgTune para obtener valores para sus parámetros en función del hardware que esté utilizando. Puede echar un vistazo a:http://pgtune.leopard.in.ua/. Sin embargo, tenga en cuenta que tendrá que probar su aplicación con los cambios que realice, para ver si hay alguna degradación del rendimiento con los cambios.
Otra cosa a considerar sería la indexación de la base de datos. Los índices ayudan a obtener los datos más rápido, sin embargo, más índices crean problemas con la carga de los datos. Por lo tanto, siempre verifique si hay índices no utilizados en la base de datos y elimínelos para reducir el mantenimiento de esos índices y mejorar la carga de datos.
