ClickHouse partition key selection - ApsaraDB for ClickHouse - Centro de documentación de Alibaba Cloud

Aprenda a seleccionar claves de partición de tabla en ApsaraDB for ClickHouse para optimizar el rendimiento y mejorar la eficiencia en la gestión de datos.

Claves de partición

La función de partición organiza los datos en segmentos lógicos según las claves especificadas y divide la información en fragmentos separados (partes) de acuerdo con la clave de partición.

En ApsaraDB for ClickHouse Enterprise Edition, si inserta varias filas en una tabla sin clave de partición, todos los datos se escriben en una sola parte nueva. Cuando una tabla utiliza una clave de partición, el sistema realiza las siguientes operaciones:

Verifica los valores de la clave de partición de las filas que se insertan.
Crea una parte de datos en el almacenamiento para cada valor único de la clave de partición.
Asigna las filas a las partes de datos correspondientes según los valores de la clave de partición.

Tabla sin clave de partición

Tabla con clave de partición

Principios fundamentales

Para reducir las solicitudes de escritura en los buckets de Object Storage Service que almacenan datos de ApsaraDB for ClickHouse Enterprise Edition, elija claves de partición con baja cardinalidad (pocos valores distintos) y campos fáciles de gestionar, como el tiempo. Las claves primarias deben cubrir los campos de filtrado más comunes en un orden lógico. Evite los campos de alta cardinalidad, el particionamiento excesivamente detallado y las claves primarias irrelevantes para aprovechar al máximo el rendimiento de ClickHouse.

El particionamiento es una herramienta de gestión de datos

Utilice el particionamiento para la expiración de datos, el almacenamiento por niveles y la eliminación por lotes, en lugar de usarlo como herramienta de optimización de consultas. Para obtener más información, consulte Choosing a Partitioning Key.
Elija un campo de baja cardinalidad como clave de partición

Mantenga el número de particiones entre 100 y 1,000. Evite usar campos de alta cardinalidad (campos con muchos valores distintos, como user_id o números de dispositivo) como claves de partición. De lo contrario, la cantidad de partes puede crecer exponencialmente, lo que degrada el rendimiento o provoca errores de "too many parts".
El método de particionamiento más común se basa en el tiempo

Particione por mes o día mediante funciones como toYYYYMM(date), toStartOfMonth(date) o toDate(date). Esto simplifica la gestión del ciclo de vida de los datos y el almacenamiento por niveles (hot/cold). Para obtener más información, consulte Custom Partitioning Key.
Las claves de partición deben alinearse estrechamente con el ciclo de vida de los datos, el archivado, la limpieza y otros requisitos de gestión

Elija dimensiones que permitan la gestión por lotes desde una perspectiva empresarial. Para obtener más información, consulte Applications of partitioning.

Recomendaciones de diseño de tablas

Priorice el particionamiento basado en tiempo

Para escenarios de registros, series temporales y monitoreo, particione por mes o día. Por ejemplo, una tabla de registros particionada por mes, donde los datos de cada mes residen en una partición independiente, ofrece las siguientes ventajas:

Gestión de datos eficiente: Elimine, archive o mueva datos por lotes según la partición. Por ejemplo, en lugar de usar ALTER TABLE DELETE para borrar datos caducados, utilice DROP PARTITION para quitar una partición completa sin examinar toda la tabla. Consulte data management para más detalles.
Implementación sencilla de la gestión del ciclo de vida de los datos (TTL): Combine particiones con directivas TTL para limpiar automáticamente los datos caducados, lo que simplifica las operaciones y el mantenimiento.
La poda de particiones mejora la eficiencia de las consultas: Al filtrar por tiempo, ClickHouse examina solo las particiones relevantes, reduce la E/S y acelera las consultas.

Evite campos de alta cardinalidad para el particionamiento

No utilice identificadores de usuario, números de pedido ni números de dispositivo como claves de partición. Por ejemplo, si una tabla usa user_id como clave de partición, cada usuario único genera una partición separada, lo que provoca los siguientes inconvenientes:

Explosión de particiones: Cada ID de usuario único genera una partición, lo que supera por mucho el rango recomendado de 100 a 1,000 y ejerce una fuerte presión sobre la gestión de metadatos y el sistema de archivos.
Fallo en la combinación en segundo plano: ClickHouse combina partes solo dentro de la misma partición. Un exceso de particiones impide una combinación eficaz y deja muchas partes pequeñas que degradan el rendimiento de consultas y escrituras.
Degradación del rendimiento de consultas: Examinar grandes volúmenes de metadatos de particiones durante las consultas reduce la eficiencia general.
Agotamiento de recursos de la instancia: Una cantidad excesiva de partes de partición consume mucha memoria y manejadores de archivos, lo que puede provocar que ClickHouse inicie lentamente o falle por completo.

Evite el particionamiento excesivamente detallado

No particione por hora, minuto o segundo a menos que el volumen de datos sea extremadamente grande y existan requisitos específicos. Por ejemplo, particionar por minuto con toYYYYMMDDhhmm(event_time) genera 1,440 particiones diarias y más de 500,000 al año, con los siguientes inconvenientes:

Demasiadas particiones: Un particionamiento demasiado fino supera por mucho el rango recomendado de 100 a 1,000, lo que aumenta significativamente la carga en la gestión de metadatos y del sistema de archivos.

Error típico: DB::Exception: Too many parts (N). Merges are processing significantly slower than inserts.
Fallo en la combinación en segundo plano: ClickHouse combina partes solo dentro de la misma partición. Un exceso de particiones impide una combinación eficaz y deja muchas partes pequeñas que degradan el rendimiento.
Degradación del rendimiento de consultas y escrituras: Examinar grandes volúmenes de metadatos de particiones reduce la eficiencia de las consultas, mientras que el número excesivo de partes también ralentiza las escrituras.

Las claves de partición deben ser campos originales o expresiones simples

Evite funciones complejas para que ClickHouse pueda aplicar eficazmente la poda de particiones.

Diseñe las claves de partición en conjunto con las claves primarias

Utilice claves primarias para cubrir los campos de filtrado consultados habitualmente y claves de partición para la gestión de datos.

Por ejemplo, para una tabla de registros que se consulta frecuentemente por rango de tiempo y nombre de servicio, y que requiere limpieza periódica de datos caducados:

Clave de partición: toYYYYMM(event_time) crea una partición por mes, lo que permite la eliminación por lotes mensual, el archivado y el almacenamiento por niveles (hot/cold).
Clave primaria: (service_name, event_time) permite que consultas como WHERE service_name = 'A' AND event_time BETWEEN ... aprovechen plenamente el índice de clave primaria para una poda eficiente de datos.

Ejemplos de diseño de tablas

CREATE TABLE logs
(
    event_time DateTime,
    service_name String,
    log_level String,
    message String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)         -- Partition by month for easy data management
ORDER BY (service_name, event_time)       -- Primary key covers commonly filtered fields

Opciones de clave de partición no recomendadas

Clave de partición como user_id (alta cardinalidad): Una partición por usuario, lo que genera demasiadas particiones, fallos de combinación y un rendimiento muy deficiente.
Clave de partición como device_id (alta cardinalidad): Igual que el caso anterior, provoca errores de "too many parts" y particiones inmanejables.
Clave de partición como order_id (alta cardinalidad): Una partición por pedido, lo que causa una fragmentación extrema.
Clave de partición como name (cadena de alta cardinalidad): Número de particiones incontrolable y difícil de gestionar.
Clave de partición como toHour(event_time) (demasiado detallada): 24 particiones por día, un número extremadamente alto de particiones con el paso del tiempo y fallos de combinación.
Clave de partición como toMinute(event_time) (extremadamente detallada): Explosión de particiones que afecta gravemente al rendimiento.
Clave primaria como campo de alta cardinalidad con orden ilógico: Por ejemplo, ORDER BY (user_id, event_time), pero las consultas suelen ser por event_time, lo que resulta en un bajo aprovechamiento del índice de clave primaria.
Clave primaria con demasiados campos: Por ejemplo, ORDER BY (a, b, c, d, e, f, g, h, i, j), lo que genera un índice de clave primaria grande y un alto consumo de memoria.
Clave primaria como campo de baja cardinalidad: Por ejemplo, ORDER BY (status), con solo unos pocos valores de estado, lo que resulta en una capacidad de poda del índice de clave primaria muy pobre.
Clave de partición y clave primaria totalmente desconectadas, y ninguna cubre condiciones de consulta comunes: Por ejemplo, la clave de partición es region y la clave primaria es type, pero las consultas suelen ser por event_time, por lo que ni la partición ni la clave primaria aceleran las consultas.