Sugerencias de uso y optimización del rendimiento para clústeres desacoplados de almacenamiento y cómputo de DWS 3.0

Escenarios

La versión 3.0 de DWS recientemente lanzada proporciona agrupación de recursos, almacenamiento masivo y la arquitectura MPP con cómputo y almacenamiento desacoplados. Esto permite una alta elasticidad, la importación y el uso compartido de datos en tiempo real, y la integración de almacenes de datos.

Para obtener más información sobre el cómputo y el almacenamiento desacoplados, consulte ¿Qué es DWS?.

Compra de un clúster

• Espacio del disco EVS

  En la versión 9.1.0.x, solo los datos de usuario de almacenamiento en columnas se almacenan en OBS, mientras que otros datos permanecen en discos locales. En consecuencia, incluso en una arquitectura desacoplada de almacenamiento y cómputo, todavía es necesario configurar discos EVS adicionales, y no solo discos de tamaño mínimo. La capacidad de desacoplamiento de almacenamiento y cómputo seguirá evolucionando en versiones futuras.

  Tabla 1 Almacenamiento de diferentes tipos de tablas

  Tipo de tabla	Ubicación de almacenamiento	Escenario
  Tabla de almacenamiento por filas, tabla temporal e índice de almacenamiento por columnas	Local, sin compresión	Consulta puntual, importación de pequeños lotes en tiempo real y actualización frecuente.
  Tabla de almacenamiento por columnas 2.0	Local, comprimido	Importación por lotes, consulta, importación de pequeños lotes en tiempo real, consulta puntual y actualización.
  Tabla de almacenamiento por columnas 3.0	OBS, comprimido	Importación por lotes, consulta y actualización por lotes de baja frecuencia.

  Almacenamiento de EVS: metadatos de almacenamiento por filas y por columnas (min/max, índices, Delta, WAL, caché de datos de OBS y archivos temporales (sort/hash) en cómputo. El tamaño se puede especificar al comprar un clúster de DWS.

  Fórmula para calcular el tamaño total requerido de almacenamiento de EVS:

  (2 copias x (Tamaño de la tabla de almacenamiento por filas + Tamaño del índice + Tamaño de la tabla Delta) + Tamaño de la caché de datos de OBS)/0.8 (reservado)

  

  Cuando el tamaño total de almacenamiento de EVS supera el 90 %, el clúster pasa al modo de solo lectura. El espacio reservado del 10 % se asigna para almacenar WAL y archivos temporales.

  • Datos activos de OBS: si especifica el tamaño de los datos activos, utilice ese valor. De lo contrario, configúrelo en el 30 % del volumen total de datos de OBS.
  • Tamaño de un índice de almacenamiento por columnas = Tamaño de datos originales sin comprimir x Ancho de la columna del índice x 3 (tasa de inflación) /Ancho total de la columna
  • Los datos de almacenamiento por columnas se evalúan en función de la relación de compresión de 3:1. Supongamos que una tabla contiene 20 columnas, dos de las cuales son claves primarias. El tamaño del índice es aproximadamente el 30 % del tamaño de los datos antes de la compresión y coincide con el tamaño de los datos después de la compresión.
  • Tamaño de Delta: Máx (10 GB, tamaño de la tabla comprimida/10) de una tabla (o partición)
  • El tamaño de un índice de almacenamiento por filas se calcula en función del 30 % del tamaño de la tabla comprimida.

  Espacio del disco EVS recomendado: El uso del algoritmo mencionado anteriormente puede ser complejo. Es recomendable configurar el espacio total del disco EVS para que coincida con el volumen total de datos después de la compresión, asumiendo una relación de compresión de 5x. Si la tabla carece de un índice (con EVS que sirve principalmente como caché), configure el espacio total del disco EVS en el 50 % o el 30 % del volumen total de datos (sin incluir los datos archivados) y, posteriormente, aumente el tamaño de la caché del disco (consulte la siguiente sección para obtener más detalles).

  Capacidad mínima

  • Clientes sensibles al rendimiento: Asegúrese de que cada DN prinicpal/en espera tenga una capacidad de disco mínima de 500 GB para lograr un throughput de 350 MB/s por disco. Por ejemplo, si se despliegan dos DN primarios y dos en espera en un ECS, se deben montar al menos cuatro discos de 500 GB en el ECS.
  • Clientes sensibles al costo: Se montan al menos 200 GB (160 MB/s por disco) en cada DN principal/en espera.
• Configuración de OBS

  OBS debe desplegarse en tres AZ y admitir sistemas de archivos paralelos.

  Rendimiento de OBS

  Si necesita ajustar las especificaciones de rendimiento de OBS, póngase en contacto con el soporte técnico. En escenarios de nube pública, no es necesario ajustar las métricas de OBS para un clúster con seis o menos DN.

• Configuración de CPU

  En un entorno de producción, se recomienda que cada nodo tenga un mínimo de 16 vCPU. Las configuraciones de 4 vCPU o 8 vCPU generalmente se utilizan solo con fines experimentales o de prueba.

  • Escenario de migración: Asegúrese de que los núcleos de CPU coincidan con los objetos de migración.
  • Nuevo escenario de despliegue: Calcule el número de núcleos de CPU necesarios dividiendo el volumen total de datos por 100 GB. Tenga en cuenta que el número de núcleos de CPU necesarios puede variar según el caso de uso específico. Si la carga computacional es alta, se recomienda aumentar el número de núcleos de CPU en consecuencia.

Optimización del diseño de tablas

Sentencias de creación de tablas

Por defecto, DWS crea tablas de almacenamiento por filas. En los escenarios de análisis OLAP, debe establecer explícitamente ORIENTATION en el almacenamiento por columnas al crear tablas.

Para obtener más información, consulte CREATE TABLE.

1

CREATE TABLE public.t1(id integer) WITH (ORIENTATION =COLUMN);

Optimización del diseño de tablas

En una arquitectura de desacoplamiento de almacenamiento y cómputo, los datos se almacenan en el Object Storage Service (OBS). Para optimizar el rendimiento, es crucial utilizar métodos de filtrado para evitar la sobrecarga innecesaria de lectura de datos de la Unidad de cómputo (CU) remota. Este enfoque mejora significativamente el rendimiento.

Métodos de filtrado

DWS es compatible con el ecosistema PostgreSQL. El almacenamiento por filas y su índice B-tree son similares a los de PostgreSQL. El almacenamiento por columnas y su índice son desarrollados por nosotros mismos. Al crear una tabla, es importante seleccionar un modo de almacenamiento, una columna de distribución, una clave de partición y un índice adecuados para garantizar que se pueda acceder rápidamente a los datos durante la ejecución de SQL, lo que reduce el consumo de E/S. La siguiente figura muestra el proceso desde el inicio de una sentencia SQL hasta la obtención de datos. Puede comprender la función de cada enfoque técnico para una mejor optimización del rendimiento.

1. Cuando se ejecuta la sentencia SQL, la tabla particionada se optimiza mediante la Columna de partición para identificar la partición específica.
2. La Columna de distribución se utiliza en una tabla hash distribuida para identificar rápidamente la partición de datos donde residen los datos. En una arquitectura de almacenamiento y cómputo acoplados, la partición de datos se encuentra en un DN, mientras que en una arquitectura de almacenamiento y cómputo desacoplados, se encuentra en un bucket.
3. En el modo de almacenamiento por filas, el índice B-tree se utiliza para localizar rápidamente la página de datos. En el modo de almacenamiento por columnas, el índice min-max se utiliza para localizar rápidamente el bloque de datos de CU que puede contener datos relevantes. Este índice es particularmente efectivo cuando se filtra en la columna PCK.
4. El sistema mantiene automáticamente el índice min-max para todas las columnas en el modo de almacenamiento por columnas. No es necesario definir índices manualmente. El índice min-max sirve como un filtro grueso. Sin embargo, los bloques de datos de CU que cumplen lcon a condición min-max no necesariamente contengan filas de datos que cumplan con la condición de filtrado. Si se define una columna de bitmap, el índice de bitmap se puede utilizar para localizar rápidamente el número de fila de los datos que cumplen con la condición de filtrado dentro de la CU. Para las CU ordenadas, también se puede emplear la búsqueda binaria para encontrar rápidamente el número de fila.
5. El almacenamiento por columnas admite índices B-tree y GIN, que pueden localizar rápidamente la CU y el número de fila de los datos que cumplen con las condiciones. Sin embargo, debido a los altos costos de mantenimiento de índices, se recomienda utilizar índices de bitmap en su lugar, a menos que haya requisitos de alto rendimiento para consultas puntuales.

Métodos de optimización

A continuación, se utiliza una sentencia de creación de tabla para describir los métodos de optimización existentes de DWS. Para obtener más información, consulte CREATE TABLE.

1

SELECT * FROM t1 WHERE t1.c1='p1';

1

SELECT *  FROM t1 WHERE t1.c1='p1';

1

SELECT * FROM t1 join t2 on t1.c3 = t2.c1;

1

SELECT * FROM t1 WHERE t1.c4 = 'hello';

1

SELECT * FROM t1 WHERE c3 > 100 and c3 < 200;

1

SELECT * FROM t1 WHERE c3 >100 and c3 < 200;

1

SELECT * FROM t1 WHERE c1 = 200 and c2 = 105;

Memoria caché de disco

DWS almacena en caché los datos a los que se accede con frecuencia en discos EVS locales para minimizar las lecturas directas desde OBS y mejorar el rendimiento de las consultas de datos. La caché de disco es exclusiva de los nodos de cómputo DN y no está presente en los CN.

Tamaño de la caché

El valor predeterminado de disk_cache_max_size es la mitad de la capacidad de EVS. Para cambiar su valor, comuníquese con el soporte técnico.

La capacidad de EVS se divide en dos secciones: la mitad se asigna para almacenar datos locales persistentes, como índices de almacenamiento de columnas, tablas de almacenamiento por filas y tablas de almacenamiento por columnas locales, mientras que la otra mitad se reserva para fines de caché. Los índices de DWS almacenan datos de índices. Si no se crea ningún índice para una tabla de almacenamiento por columnas, puede aumentar el valor de disk_cache_max_size.

Estado de la caché

Cuando un usuario consulta datos, el sistema primero verifica si los datos existen en la caché de disco local. Si los datos no están presentes, el sistema los lee desde OBS y los almacena en caché en el disco local para su acceso futuro. Este mecanismo de almacenamiento en caché puede mejorar significativamente la velocidad de las consultas de datos de OBS.

Por defecto, la caché de disco utiliza dos discos en modo activo/en espera como medios de caché. Puede consultar los siguientes parámetros para ver la información relacionada:

• query the disk_cache_base_paths: Puede utilizarlo para ver, agregar o eliminar rutas de disco de caché. Para configurar este parámetro, comuníquese con el soporte técnico.
• disk_cache_max_size: Puede utilizarlo para ver y ajustar el tamaño de la caché de disco.

Utilice la vista pgxc_disk_cache_all_stats para ver la relación de aciertos de caché actual y el uso de disco de cada DN.

Figura 1 Resultado de la consulta de pgxc_disk_cache_all_stats

Escritura doble en caché

La habilitación de Escritura doble en caché puede mejorar el rendimiento de la primera consulta de datos. Específicamente, cuando los datos se escriben en el OBS remoto, también se escriben en la caché de disco local. Esto mejora significativamente la eficiencia de lectura durante el acceso inicial a los datos. Puede utilizar el disk_cache_dual_write_option para configurar si se habilita la escritura doble en caché. Las opciones son las siguientes:

• none: Deshabilitar la escritura doble en caché.
• hstore_only (valor predeterminado): Habilitar la escritura doble en caché solo para la tabla HStore durante la fusión delta.
• all: Habilitar la escritura doble en caché tanto para las tablas v3 comunes como para las tablas HStore.

Borrado de la caché

Utilice la función pgxc_clear_disk_cache() para borrar todas las cachés de disco.

Espacio insuficiente en el clúster y ajuste del espacio de la caché de disco

Para solucionar la escasez de recursos en un clúster, considere reducir el espacio de la caché de disco. Esto puede ayudar a liberar espacio en disco y aliviar el problema, especialmente para los clústeres que ya han utilizado una cantidad significativa de espacio de la caché de disco.

Ajuste el parámetro disk_cache_max_size para reducir el espacio real de la caché de disco y aliviar la insuficiencia de espacio del clúster.

Por ejemplo, la capacidad total del disco es de 1,000 GB y el valor de disk_cache_max_size es de 500 GB, y el uso real del disco consultado en la vista pgxc_disk_cache_all_stats es de 450 GB. Cuando el uso total del disco alcanza los 900 GB, se activará el problema ThresholdReadRisk, lo que indica que no hay suficientes recursos restantes. Si no hay tablas de almacenamiento en columna de la versión 2.0 o recursos de índice que se puedan borrar, puede cambiar el valor de disk_cache_max_size a 300 GB o un valor menor. Reducir la caché de disco disponible puede deteriorar el rendimiento de las consultas.

Las alarmas de uso de disco se determinan de la siguiente manera:

• Advertencia de capacidad: El uso del espacio en disco o el uso del descriptor de archivo excede el valor de ThresholdReadOnly (80 % por defecto). El registro contendrá "El uso del disco en el nodo %u ha alcanzado el umbral de riesgo del 80 %."
• Capacidad insuficiente: El uso del espacio en disco o el uso del descriptor de archivo excede el valor de ThresholdReadRisk (90 % por defecto), lo que hace que el clúster sea de solo lectura. El registro mostrará "El uso del disco en el nodo %u ha alcanzado el umbral de solo lectura del 90 %."
• Capacidad extremadamente insuficiente: el uso del espacio en disco o de descriptores de archivos supera el valor de ThresholdReadDanger (95 % por defecto), lo que provoca que los DN secundarios y en espera finalicen y que el DN principal se reinicie. El registro mostrará "El uso del disco en el nodo %u ha alcanzado el umbral peligroso del 95 %."

Rendimiento de inserción

Almacenamiento de bucket

El almacenamiento de bucket es un método de particionamiento de datos que, de manera similar a la tecnología de particionamiento, agrupa los datos con los mismos valores de atributos. Este enfoque facilita el ajuste del mapeo entre el almacenamiento y la computación, lo que permite una separación de los recursos de almacenamiento y computación, y permite un escalamiento elástico y una asignación bajo demanda de los recursos de computación.

Por ejemplo, si hay ocho buckets y dos DN, cada DN sería responsable de cuatro buckets. Por el contrario, si hay cuatro DN, cada DN sería responsable de dos buckets.

Figura 2 Almacenamiento de bucket

Optimización de importación

Los datos deben guardarse en la base de datos por lotes, con E/S asincrónica.

Agrupamiento en lotes: Esta técnica se emplea para evitar Unidades de Compresión (CU) pequeñas y mejorar el rendimiento de las consultas posteriores.

E/S asincrónica: Tras el desacoplamiento del almacenamiento y la computación, la latencia para escribir datos en OBS es aproximadamente diez veces mayor que la de escribir datos en EVS. La E/S asincrónica optimiza el rendimiento de lectura y escritura.

• Para las tablas particionadas, las tablas 2.0 requieren solo el agrupamiento en lotes por partición. Las tablas 3.0, en comparación, requieren un agrupamiento en lotes por buckets (equivalente a particiones de nivel 2), lo que puede consumir más memoria y espacio en disco.
• Solo las tablas distribuidas por hash requieren un agrupamiento en lotes por bucket.

Sugerencia y sobrecarga del agrupamiento en lotes

Sobrecarga

Number of partitions: #Np
Number of buckets on each node: #Nb
RowGroup size before compression: #Nr
Maximum size of a single bucket: #Mb = max (partition_max_cache_size/partition_men_batch, 16M) = 16M (default configuration)

Single-concurrency batching consumption: #Np * #Nb * #Nr
Single-concurrency batching memory consumption: partition_max_cache_size. The default value is 2 GB.
Single-concurrency batching disk consumption: #Np * #Nb * #Nr * 1.2 (bloat rate) - Memory consumption 

Assume that data is copied at a time, 1000 partitions are involved, #Nb ≈ 10, the size of a single record is 1 KB, and the total batching size is 10,000 rows.
Single-concurrency batching consumption: 1000 * 10 * 1K * 10000 * 1.2 = 120 GB

Sugerencias

1. Optimización de la capa de aplicación: El factor clave es el número de particiones. Se recomienda utilizar una sola partición para importar datos a la base de datos. Si el espacio consumido de una sola operación de procesamiento por lotes simultánea se reduce de 120 GB a 120 MB, la memoria se puede utilizar directamente para el procesamiento por lotes.
2. Optimización del kernel de la base de datos: Modifique el parámetro min_batch_rows para ajustar el tamaño del lote. Puede ejecutar la sentencia SET para aplicar los cambios para la sesión actual o modificar el archivo de configuración para que los cambios sean efectivos inmediatamente.