clickhouse utiliza cierta optimización y experiencia
1. La consulta requiere en gran medida el filtrado de claves de partición y el filtrado de claves primarias, como donde día = hoy() e itime = ahora().
2. Al crear una tabla, elegir la clave de partición y la clave de clasificación adecuadas es la clave para la optimización.
3. Si no se permiten claves primarias duplicadas (y no se requiere la deduplicación oportuna), se recomienda utilizar el tipo de tabla: ReplicatedReplacingMergeTree Para las declaraciones de creación de tablas, consulte /blog/2019/. 27/03/baja cardinalidad.
7. Para completar consultas complejas localmente tanto como sea posible, reduzca la cantidad de datos y transmisión de red por adelantado y acelere la velocidad de la consulta. Al crear una tabla distribuida, intente dividir los fragmentos. según el hash de clave primaria. Por ejemplo, desea acelerar la velocidad de consulta del recuento seleccionado (uid distinto) del grupo table_all por país, sistema operativo. Al crear la tabla distribuida table_all, la clave del fragmento es cityHash64 (país, sistema operativo). consulte https://clickhouse.tech/docs/en/sql-reference/functions/hash-functions/.
8. Al calcular los valores del indicador para diferentes combinaciones de dimensiones, utilice with rollup o with cube en lugar de la cláusula union all.
9. Al crear una tabla, siga la convención de nomenclatura: nombre de tabla distribuida = sufijo de nombre de tabla local "_all". Seleccione Por favor opere la tabla distribuida directamente.
10. Los funcionarios han señalado que el tipo Nullable casi siempre reducirá el rendimiento, porque al almacenar columnas Nullable, es necesario crear un archivo adicional para almacenar la etiqueta NULL y las columnas Nullable no se pueden indexar. Por lo tanto, a menos que existan circunstancias muy especiales, debe usar directamente el valor predeterminado del campo para indicar que está vacío o especificar un valor que no tenga sentido en el negocio (por ejemplo, use -1 para indicar que no hay ID de producto)
11. Los índices dispersos son diferentes de mysql. No existe el principio más a la izquierda en el árbol B, por lo que al consultar ck, en la condición donde, la columna con una cardinalidad mayor (es decir, la columna con mayor discriminación) viene primero, y la columna con una cardinalidad más pequeña (la columna con menor discriminación) en la parte posterior.
12. Al unir varias tablas, se debe cumplir el principio de la tabla pequeña de la derecha. Cuando se asocia la tabla de la derecha, se carga en la memoria y se compara con la tabla de la izquierda. >
13. Análisis multidimensional, columna de consulta No debe haber demasiadas. Las condiciones del filtro deben estar particionadas (seleccione dim1, dim2, agg1(xxx), agg2(xxx) de la tabla donde xxxx se agrupa por dim1, dim2) <. /p>
14. SELECT * está prohibido y no se puede obtener. ¡Obtenga datos originales! (Clickhouse no es un almacén de datos. Las consultas que extraen exclusivamente datos de la tabla original deben estar prohibidas, como seleccionar a, b, c, f, e, país de xxx)
Clave de partición y En teoría, la clave de clasificación no se puede modificar, así que trate de pensar con claridad al crear tablas y bases de datos.
0. La tabla de hechos debe estar particionada. La granularidad de la partición se determina de acuerdo con las características del negocio y no debe ser ni demasiado gruesa ni demasiado fina. Actualmente estamos particionando por día, y la partición por hora, semana y mes también es común (las tablas query_log y trace_log en las tablas del sistema están particionadas por mes de forma predeterminada).
1. La clave de partición puede filtrar una gran cantidad de datos. Se recomienda utilizar toAAAAMMDD() para particionar la clave de partición por día. Si la cantidad de datos es muy pequeña, alrededor de 1 millón. Se recomienda utilizar toYYYYMM () para particionar por mes. Demasiadas particiones causarán Ocupar una gran cantidad de recursos tendrá un gran impacto en la estabilidad del clúster.
2. La clave de partición debe usar campos de fecha y fecha y hora, evite claves de partición de tipo cadena.
3. Cada SQL debe usar una clave de partición; de lo contrario, se leerá una gran cantidad de datos. Si se alcanza el límite de memoria del clúster, se rechazará directamente
4. La clave de clasificación también es una condición de filtrado muy importante. Teniendo en cuenta que ck es una biblioteca OLAP, la clave de clasificación también es la principal. clave de ck de forma predeterminada. La biblioteca loap recomienda que se utilice la clave de partición. Los campos con cardinalidad relativamente pequeña, como el país, son mejores que la marca de tiempo.
5. No utilice claves de partición ni claves primarias demasiado largas.
6. El índice de CK no es el índice del árbol B de MySQL, sino un índice disperso similar al estilo de registro de Kafka. Por lo tanto, no es necesario considerar el principio más a la izquierda, sino columnas con mayor cardinalidad (es decir, Se recomiendan columnas con mayor discriminación) al frente y columnas con menor cardinalidad (columnas con menor discriminabilidad) en la parte posterior. Además, no se recomienda utilizar columnas con cardinalidad particularmente grande (como ID de pedido, etc.) como índices.
Demasiadas particiones pueden causar algunos problemas fatales en el clúster. No se recomienda tener una granularidad demasiado fina en el número de particiones, ni demasiadas particiones. Por experiencia, se recomienda que de 1 a 10 particiones sean suficientes para mil millones de datos. recursos de hardware.
1. El rendimiento de la consulta seleccionada se reduce. Demasiadas particiones provocarán que se abra una gran cantidad de identificadores de archivos, lo que afectará al clúster.
2. Demasiadas particiones causarán problemas como reinicio lento del clúster, aumento de la presión de zk, inserción lenta, etc.
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/custom-partitioning-key/