Uso de la caché de disco para mejorar el rendimiento de las consultas

Escenarios

A medida que avanza el cómputo en la nube, las tecnologías de desacoplamiento de almacenamiento y cómputo se han vuelto cada vez más sofisticadas. Muchas empresas ahora almacenan grandes cantidades de datos de usuarios en la nube. Esto aumenta las demandas frecuentes de lectura-escritura en OBS, lo que convierte la velocidad de acceso a los datos en un problema clave de rendimiento. Mejorar la eficiencia del procesamiento de datos en la nube sigue siendo un desafío crítico.

DWS acelera el acceso a los datos mediante el uso de la caché de disco local y gestiona el espacio de la caché de forma eficaz con la política de los menos utilizados recientemente (LRU). DWS también proporciona la función de precarga de caché para escenarios entre VW (sigla que significa almacén virtual de datos). La función carga los datos seleccionados, como tablas o particiones, en la caché inmediatamente después de crear un VW elástico, lo que aumenta la velocidad de las consultas.

Esta función solo está disponible para clústeres de 9.1.0.x o posterior. La cola de tiempo de vida (TTL) solo está disponible para clústeres de 9.1.1.x o versión posterior.

LRU de cola múltiple

• LRU

  La política de caché LRU organiza los datos almacenados en la caché en una cola. Los datos nuevos o a los que se accede se mueven al frente de la cola para evitar su eliminación prematura. El sistema elimina primero los datos más antiguos cuando el búfer se llena.

  DWS utiliza el algoritmo LRU-2Q para evitar la contaminación de la caché LRU. Mantiene los datos de los servicios principales a los que se accede con frecuencia en la caché, incluso cuando se procesan grandes cantidades de información antigua.

  LRU2Q utiliza tres colas: A1in, A1out y Am. En el primer acceso, los datos se almacenan en la cola A1in. Si A1in se llena (por defecto corresponde al 25 % del tamaño total de la cola, pero se puede modificar según sea necesario), los datos desalojados se mueven a la cola A1out. Los datos de A1out no se almacenan en la caché, pero actúan como almacenamiento adicional para A1in. Si se accede nuevamente a los datos de A1out, se promueven a la cola Am. La cola Am almacena los datos más utilizados.

• TTL

  La política TTL mantiene los datos recién importados en la caché durante un período de tiempo sin eliminarlos. Durante este período, todos los datos TTL tienen la misma prioridad máxima. Ningún dato se elimina antes de tiempo solo por el hecho de estar próximo a expirar. Si el búfer TTL se queda sin espacio, el sistema toma espacio de la cola LRU para permitir la escritura de datos TTL. El parámetro GUC disk_cache_ttl_max_ratio establece el espacio máximo para la cola TTL, con un valor predeterminado de 0.5 (la mitad del búfer total). Una vez que la cola TTL alcanza su límite y llegan nuevos datos, el sistema elimina los datos más antiguos a su espacio LRU.

  Escenario de aplicación: TTL funciona para tablas de datos de pequeña escala que deben persistir localmente. Puede establecer un TTL más largo para las tablas permanentes para mantener sus datos seguros y ajustar el TTL para las tablas temporales en función del tiempo de actividad de los datos calientes.

• Cola múltiple

  A medida que los datos crecen en escenarios masivos de big data, las necesidades de almacenamiento y el uso de recursos aumentan rápidamente. Para satisfacer las demandas de los usuarios que acceden a los datos en diferentes períodos, los sistemas gestionan la información separándola en las categorías de caliente (de uso frecuente) y fría (a la que rara vez se accede). Esto mejora la eficiencia de la caché local.

  Por ejemplo, en un sistema de análisis de tráfico de red, los usuarios suelen centrarse en incidentes de seguridad recientes o en la actividad de la red en el último mes, pero rara vez revisan datos más antiguos. Los datos se clasifican como calientes y fríos en función del tiempo.

  Los datos se clasifican como calientes o fríos en función de la frecuencia con la que se accede o se actualizan.

  • Los datos calientes se utilizan y modifican con frecuencia, es probable que se necesiten de nuevo pronto y requieren una respuesta de acceso rápida.
  • Los datos fríos rara vez se cambian o se accede a ellos y no necesitan respuestas rápidas.

  Los datos calientes deben almacenarse en la caché local siempre que sea posible. Los datos fríos deben aprovechar la localidad espacial almacenando en caché los datos a los que se accede y los datos cercanos para minimizar las lecturas futuras de OBS y también deben tener mayores posibilidades de ser eliminados en comparación con los datos calientes. En DWS, los datos fríos tienen un espacio en disco dedicado de 1 GB gestionado por la cola A0, siguiendo la política LRU

  DWS emplea un sistema de colas múltiples basado en LRU. Categoriza los datos en tres tipos utilizando los atributos TTL y caliente/frío: los datos calientes con un TTL van a la cola TTL, los datos calientes sin un TTL entran en la cola LRU-2Q y los datos fríos se asignan a la cola A0.

  Durante la lectura y escritura de datos, DWS selecciona la cola que se va a llenar y leer para maximizar la utilización de la caché.

  Tabla 1 Mecanismo de lectura y escritura de datos de DWS

  Operación	Llenado de la cola en caso de falla	Llenado de la cola en caso de escritura de datos
  Importación (con escritura doble de caché habilitada)	TTL / LRU - 2Q / A0	TTL / LRU - 2Q / A0
  Consulta	TTL / LRU - 2Q / A0	N/D
  Precarga	N/D	TTL / LRU - 2Q / A0

  Tomemos como ejemplo la operación de consulta. Si no se encuentran los datos durante la lectura de datos, el sistema verifica si los datos son datos poco utilizados. Los datos poco utilizados se almacenan en la caché A0. Para los datos más utilizados, el sistema verifica si la tabla tiene un parámetro TTL. Si el TTL está configurado y los datos no han caducado, se mueven al búfer TTL o al búfer LRU-2Q.

• Desalojo

  La cola A0 tiene un tamaño de búfer fijo de 1 GB. Las colas TTL y LRU-2Q comparten el espacio de búfer definido por el parámetro GUC disk_cache_max_size. Inicialmente, la cola LRU-2Q utiliza este espacio. Cuando se accede a datos con atributo TTL o si caduca gran cantidad de datos TTL, el sistema ajusta la asignación entre las colas TTL y LRU-2Q para optimizar el uso de la caché. La cuota máxima de la cola TTL no puede exceder el límite establecido por disk_cache_ttl_max_ratio.

  • Desalojo de la cola TTL

    Los datos nuevos que ingresan a la cola TTL desplazan los datos caducados a la cola LRU-2Q.

    Un subproceso en segundo plano desaloja regularmente los datos caducados de la TTL y los mueve a la cola LRU-2Q.

    Si el espacio TTL alcanza su límite sin datos caducados, se activa la política LRU, que envía los datos desalojados a la cola LRU-2Q.

    Cuando se eliminan los datos de la tabla para los que se ha establecido un tiempo de caducidad, los subprocesos en segundo plano eliminan periódicamente los datos no válidos de la TTL.

  • LRU: Desalojo de colas 2Q

    Si se insertan datos nuevos y el espacio LRU alcanza el límite superior, se activa la política LRU y los datos desalojados se borran de la caché.

    Cuando la cola TTL tiene poco espacio, pero no ha alcanzado su límite, toma espacio de la cola LRU-2Q. Si el espacio de la cola LRU-2Q está lleno, se inicia el desalojo LRU.

    Cuando se eliminan los datos de la tabla para los que se ha establecido un tiempo de caducidad, los subprocesos en segundo plano eliminan periódicamente los datos no válidos de la LRU-2Q.

Cachés de disco múltiple

Los entornos en la nube enritan el tráfico para acceder a varios discos en la nube a través de tarjetas de interfaz de red (NIC) separadas, lo que permite combinar sus anchos de banda. Cuando se utilizan varios discos EVS, DWS permite configurarlos como rutas de caché, distribuyendo los archivos de caché en estos discos para mejorar la velocidad de acceso. Por defecto, tanto los discos primarios como los en espera sirven como medios de caché para el DN primario en el nodo actual durante el funcionamiento normal del clúster, lo que optimiza el rendimiento y utiliza el espacio en disco disponible de manera eficiente. Puede consultar los siguientes parámetros para ver la información relacionada:

disk_cache_base_paths: Puede utilizarlo para ver, agregar o eliminar una ruta de caché.No puede cambiar su valor. Para cambiarlo, póngase en contacto con el soporte técnico. Por ejemplo, el nombre de la instancia es h10dn1.

La ruta de caché de disco múltiple predeterminado del DN primario es el siguiente:

• Ruta 1: /DWS/data1/h10dn1/primary0/disk_cache
• Ruta 2: /DWS/data2/h9dn1/primary0_disk_cache

La ruta de caché de disco múltiple predeterminado del DN en espera es el siguiente:

• Ruta: /DWS/data2/h9dn1/secondry/disk_cache

La ruta de caché del DN en espera comparte el mismo disco que la ruta 2 del DN primario. Si el DN en espera se convierte en primario, el espacio máximo de caché de disco disminuye a 1 GB, lo que reduce significativamente el rendimiento. Restaure el clúster a su estado equilibrado de inmediato.

Precarga de caché

En la arquitectura con almacenamiento y cómputo desacoplados, DWS admite clústeres entre VW. Los VW acceden a los datos compartidos, pero sus cachés permanecen separados. Los VW recién creados comienzan con cachés vacías, lo que puede afectar a la velocidad de las consultas. Para resolver esto, DWS ofrece la precarga de caché que permite a los usuarios transferir datos desde el almacenamiento remoto a las cachés locales. La precarga de caché admite dos modos.

• Table data prefetch: Precargue los datos de la tabla A.

  1 2 3 4

  /*Pre-load data in table A to the A1in queue.*/ EXPLAIN warmup SELECT * FROM A; /*Pre-load the data in table A to the Am queue.*/ EXPLAIN warmup hot SELECT * FROM A;

• Partition data prefetch: Precargue los datos de la partición p1 de la tabla A.

  1 2 3 4

  /*Pre-load the data in partition p1 of table A to the A1in queue.*/ EXPLAIN warmup SELECT * FROM A partition(p1); /*Pre-load the data in partition p1 of table A to the Am queue.*/ EXPLAIN warmup hot SELECT * FROM A partition(p1);

Consulta de datos almacenados en caché

Consulta del espacio de disco y la tasa de acierto

Puede ejecutarpgxc_disk_cache_all_stats para ver el estado actual de la caché del disco. El comando es el siguiente:

1

SELECT * FROM pgxc_disk_cache_all_stats;

Habilitación de la memoria caché de disco

Por defecto, la memoria caché de disco está habilitada para clústeres en la nube. Es decir, el acceso a todas las tablas v3 utiliza la memoria caché de disco. Para verificar si la memoria caché de disco está habilitada en su clúster, siga estos pasos. La siguiente información es solo para referencia. No es necesario configurarlo por separado. Si necesita configurarlo, comuníquese con el soporte técnico.

1. Ejecute los siguientes comandos en el DN:

   SHOW enable_aio_scheduler; 
   SHOW obs_worker_pool_size;

   Asegúrese de que enable_aio_scheduler=on y obs_worker_pool_size >=4.

2. Ejecute el siguiente comando en el CN:

   1	SHOW enable_disk_cache

   Asegúrese de que enable_disk_cache=on.

Se deben cumplir las dos condiciones anteriores.

Especificación de una política de memoria caché a nivel de tabla

Hay cuatro políticas de memoria caché admitidas por la disk cache.

• HPN(HOT PARTITION NUMBER)

  Establezca la cache policy en HPN : N durante las operaciones CREATE TABLE o ALTER TABLE. Especifique un valor para N entre -1600 y 1600. Los datos de las N particiones más recientes se almacenarán en caché en caliente, mientras que las particiones más antiguas permanecerán en caché en frío. Si N es 0, todos los datos de todas las particiones se almacenarán en caché en frío. HPN solo es válido para tablas de partición range y tablas de partición list en tablas V3.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

  CREATE TABLE IF NOT EXISTS lineitem ( L_ORDERKEY BIGINT NOT NULL , L_PARTKEY BIGINT NOT NULL , L_SUPPKEY BIGINT NOT NULL , L_LINENUMBER BIGINT NOT NULL , L_QUANTITY DECIMAL(15,2) NOT NULL , L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL , L_DISCOUNT DECIMAL(15,2) NOT NULL , L_TAX DECIMAL(15,2) NOT NULL , L_RETURNFLAG CHAR(1) NOT NULL , L_LINESTATUS CHAR(1) NOT NULL , L_SHIPDATE DATE NOT NULL , L_COMMITDATE DATE NOT NULL , L_RECEIPTDATE DATE NOT NULL , L_SHIPINSTRUCT CHAR(25) NOT NULL , L_SHIPMODE CHAR(10) NOT NULL , L_COMMENT VARCHAR(44) NOT NULL ) with ( orientation = column, colversion = 3.0, cache_policy = 'HPN : 3' ) TABLESPACE cu_obs_tbs DISTRIBUTE BY HASH(L_ORDERKEY) PARTITION BY RANGE(L_SHIPDATE) ( PARTITION L_SHIPDATE_4 VALUES LESS THAN ('1993-01-01 00:00:00'), -- Cold cache PARTITION L_SHIPDATE_5 VALUES LESS THAN ('1994-01-01 00:00:00'), -- Cold cache PARTITION L_SHIPDATE_3 VALUES LESS THAN ('1995-01-01 00:00:00'), -- Cold cache PARTITION L_SHIPDATE_1 VALUES LESS THAN ('1996-01-01 00:00:00'), -- Cold cache PARTITION L_SHIPDATE_2 VALUES LESS THAN ('1997-01-01 00:00:00'), -- Hot cache PARTITION L_SHIPDATE_7 VALUES LESS THAN ('1998-01-01 00:00:00'), -- Hot cache PARTITION L_SHIPDATE_6 VALUES LESS THAN ('1999-01-01 00:00:00') -- Hot cache );

• HPL(HOT PARTITION LIST)

  Establezca la cache policy en HPL : , , ... durante las operaciones CREATE TABLE o ALTER TABLE. Especifique el nombre de la partición caliente. El sistema almacenará los datos de esta partición en la caché caliente, mientras que los datos de otras particiones se colocarán en la caché fría. HPL solo es válido para tablas particionadas por range y tablas particionadas por list en tablas V3.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

  CREATE TABLE IF NOT EXISTS nation ( N_NATIONKEY INT NOT NULL, N_NAME CHAR(25) NOT NULL, N_REGIONKEY INT NOT NULL, N_COMMENT VARCHAR(152) ) WITH ( orientation = column, colversion = 3.0, cache_policy = 'HPL : ASIA, AMERICA, REST' ) TABLESPACE cu_obs_tbs DISTRIBUTE BY ROUNDROBIN PARTITION BY LIST(N_NAME) ( PARTITION ASIA VALUES ('INDIA', 'INDONESIA', 'JAPAN'), --Hot cache PARTITION EUROPE VALUES ('FRANCE', 'GERMANY', 'UNITED KINGDOM'), -- Cold cache PARTITION AFRICA VALUES ('ALGERIA', 'ETHIOPIA', 'KENYA'), -- Cold cache PARTITION AMERICA VALUES ('ARGENTINA', 'BRAZIL', 'CANADA'), --Hot cache PARTITION REST VALUES (DEFAULT) --Hot cache );

• NONE

  Establezca la cache policy en NONE durante el comando CREATE TABLE o ALTER TABLE. Después de eso, todos los datos de la tabla se almacenan en caché en frío.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

  CREATE TABLE IF NOT EXISTS partsupp ( PS_PARTKEY BIGINT NOT NULL, PS_SUPPKEY BIGINT NOT NULL, PS_AVAILQTY BIGINT NOT NULL, PS_SUPPLYCOST DECIMAL(15,2) NOT NULL, PS_COMMENT VARCHAR(199) NOT NULL ) WITH ( orientation = column, colversion = 3.0, cache_policy = 'NONE' ) TABLESPACE cu_obs_tbs DISTRIBUTE BY HASH (PS_PARTKEY); -- Cold cache

• ALL

  Establezca la cache policy en ALL durante el comando CREATE TABLE o ALTER TABLE. Después de eso, todos los datos de la tabla se almacenan en caché en caliente.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  CREATE TABLE IF NOT EXISTS orders ( O_ORDERKEY BIGINT NOT NULL, O_CUSTKEY BIGINT NOT NULL, O_ORDERSTATUS CHAR(1) NOT NULL, O_TOTALPRICE DECIMAL(15,2) NOT NULL, O_ORDERDATE DATE NOT NULL, O_ORDERPRIORITY CHAR(15) NOT NULL, O_CLERK CHAR(15) NOT NULL, O_SHIPPRIORITY BIGINT NOT NULL, O_COMMENT VARCHAR(79) NOT NULL ) WITH ( orientation = column, colversion = 3.0, cache_policy = 'ALL' ) DISTRIBUTE BY ROUNDROBIN; -- Hot cache

Configuración de la política de TTL

Al crear una tabla, establezca el parámetro a nivel de tabla disk_cache_ttl para almacenar en caché los datos de la tabla mediante la política de TTL. disk_cache_ttl define cuánto tiempo permanecen los datos recién importados en la caché. Utiliza un formato de intervalo, con valores que van desde 1 segundo hasta 100 años.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

CREATE TABLE IF NOT EXISTS ProductDimension
(
    ProductID INT,
    ProductName VARCHAR(100),
    Category VARCHAR(50),
    Price DECIMAL(10, 2),
    Description TEXT
)
WITH (
 orientation = column,
 colversion = 3.0,
 disk_cache_ttl = '1 day'
)
DISTRIBUTE BY ROUNDROBIN; -- Hot cache

Escenarios TTL típicos

• Las tablas de dimensiones tienen un tamaño de datos pequeño con cambios mínimos, pero una alta frecuencia de acceso. Puede establecer un TTL más largo, como un año, para mantener los datos en la caché y evitar su reemplazo durante las consultas en tablas más grandes. Esto permite un acceso rápido a los datos durante todo el año.

  Establezca disk_cache_ttl en 1 año para una nueva tabla de dimensiones.

  1	CREATE TABLE dimension_table(a int, b text) with (orientation = column, COLVERSION = 3.0, disk_cache_ttl = '1 year');

  Establezca disk_cache_ttl para una tabla de dimensiones existente ejecutando el comando ALTER.

  Si no está seguro de la hora a la que se importaron los datos de la tabla, establezca disk_cache_ttl en 10 años.

  1	ALTER TABLE dimension_table SET (disk_cache_ttl = '10 years');

  También puede establecerlo en un año y luego realizar VACUUM FULL en la tabla de dimensiones para actualizar la hora de importación de datos.

  1 2	ALTER TABLE dimension_table set (disk_cache_ttl = '1 years'); VACUUM FULL dimension_table;

• Tablas en tiempo real que no se actualizan con frecuencia se utilizan principalmente para la importación y consulta de datos. Puede establecer un TTL adecuado para estas tablas según sea necesario. Por ejemplo, si accede con frecuencia a los datos del último medio día, puede establecer el TTL en 0.5 día.

  1	ALTER TABLE dimension_table set (disk_cache_ttl = '0.5 day');

• Las tablas en tiempo real se actualizan con frecuencia y las operaciones UPSERT se realizan con frecuencia. Puede agregar el tiempo TTL a las tablas en función del rango de tiempo UPSERT para mejorar el rendimiento de la operación UPSERT. Por ejemplo, si UPSERT se realiza en los datos importados en los últimos dos días, puede establecer el TTL en dos días.

  1	ALTER TABLE dimension_table set (disk_cache_ttl = '2 days');

Preguntas frecuentes

1. ¿Por qué el comando du o ls muestra que el directorio de la disk cache ocupa mucho más espacio que el tamaño real de los datos? (Solo el personal de soporte técnico puede ejecutar los comandos du y ls).

   El uso de la disk cache indica la mayor cantidad de datos almacenados registrados, no el tamaño actual de los datos almacenados en caché. Por ejemplo, si importa 100 GB de datos, realiza operaciones como UPSERT para expandirlos a 200 GB y luego ejecuta VACUUM para reducirlos a 100 GB, la disk cache todavía refleja el pico de 200 GB a pesar de contener solo 100 GB de datos reales. Los datos no válidos se eliminan solo cuando se agota la disk cache y se activa la política de desalojo LRU.

2. ¿La disk cache comenzará a desalojar datos automáticamente? ¿Por qué la marca de agua del disco se mantiene en su nivel más alto?

   Sí. El desalojo comienza cuando el uso del disco alcanza el límite máximo (predeterminado: 50 % del espacio total del disco para discos activos y en espera) o alcanza un uso del 80 %. El desalojo marca las ubicaciones de la caché como libres, pero no elimina los datos. Los datos nuevos reemplazan estos datos marcados. Esto mantiene el uso del disco igual, manteniendo una marca de agua alta.

3. ¿Por qué no disminuyen los datos de la caché de disco después de eliminar una tabla, a pesar de que OBS muestra que la tabla fue eliminada?

   Eliminar una tabla no elimina sus datos almacenados en la caché de disco. El mecanismo LRU interno borra automáticamente los datos almacenados en la caché para tablas que no existen. Este proceso no tiene impacto en la funcionalidad.

4. ¿Por qué el uso de la caché de cada nodo varía considerablemente?

   El uso de la caché varía entre los nodos debido a varias razones. Varía naturalmente debido a las limitaciones de la caché de un solo nodo. Los retrasos de las consultas permanecen sin cambios. Los factores clave que influyen son los siguientes:

   • Hora en la que se agregan diferentes instancias al clúster.
   • Cantidad de tablas en diferentes VW.
   • Distribución de datos de las tablas y los datos a los que acceden las aplicaciones. Los datos a los que accede una aplicación pueden estar en un nodo.
   • La diferencia de tiempo de VACUUM FULL en diferentes nodos. VACUUM FULL duplica el espacio de caché utilizado por las tablas. Con el tiempo, el mecanismo interno LRU elimina los datos almacenados en caché innecesarios.