Guía de traducción de SQL de Amazon Redshift

Los usuarios que mueven datos entre ClickHouse y Redshift notarán de inmediato que ClickHouse ofrece una gama de tipos más amplia, y además menos restrictiva. Mientras que Redshift exige a los usuarios especificar las posibles longitudes de las cadenas, incluso cuando son variables, ClickHouse elimina esa restricción y esa carga al almacenar las cadenas como bytes sin codificación. Por lo tanto, el tipo String de ClickHouse no tiene límites ni requiere especificar una longitud.

Además, puede sacar partido de Arrays, Tuples y Enums, que no existen en Redshift como tipos de primera clase (aunque Arrays/Structs pueden imitarse con SUPER), una limitación que suele frustrar a los usuarios. ClickHouse además permite persistir estados de agregación, ya sea en tiempo de consulta o incluso en una tabla. Esto permite preagregar los datos, normalmente mediante una vista materializada, y puede mejorar drásticamente el rendimiento de las consultas más habituales.

A continuación, mostramos el tipo equivalente de ClickHouse para cada tipo de Redshift:

Tanto ClickHouse como Redshift utilizan el concepto de «clave de ordenación», que define cómo se ordenan los datos al almacenarlos. Redshift define la clave de ordenación mediante la cláusula SORTKEY:

CREATE TABLE some_table(...) SORTKEY (column1, column2)

En comparación, ClickHouse usa una cláusula ORDER BY para especificar el criterio de ordenación:

CREATE TABLE some_table(...) ENGINE = MergeTree ORDER BY (column1, column2)

En la mayoría de los casos, puede usar las mismas columnas y el mismo orden de la clave de ordenación en ClickHouse que en Redshift, siempre que use el tipo COMPOUND predeterminado. Cuando se agregan datos a Redshift, debe ejecutar los comandos VACUUM y ANALYZE para reordenar los datos recién agregados y actualizar las estadísticas para el planificador de consultas; de lo contrario, el espacio no ordenado aumenta. En ClickHouse no se requiere ningún proceso de este tipo.

Redshift admite un par de funciones prácticas para las claves de ordenación. La primera son las claves de ordenación automáticas (mediante SORTKEY AUTO). Aunque esto puede ser apropiado para empezar, las claves de ordenación explícitas garantizan el mejor rendimiento y la mayor eficiencia de almacenamiento cuando la clave de ordenación es óptima. La segunda es la clave de ordenación INTERLEAVED, que da el mismo peso a un subconjunto de columnas de la clave de ordenación para mejorar el rendimiento cuando una consulta usa una o más columnas de ordenación secundarias. ClickHouse admite proyecciones explícitas, que logran el mismo resultado final con una configuración ligeramente distinta.

Debe tener en cuenta que el concepto de “clave primaria” representa cosas diferentes en ClickHouse y Redshift. En Redshift, la clave primaria se asemeja al concepto tradicional de los RDBMS destinado a aplicar restricciones. Sin embargo, no se aplican estrictamente en Redshift y, en cambio, actúan como indicaciones para el planificador de consultas y la distribución de datos entre nodos. En ClickHouse, la clave primaria denota las columnas usadas para construir el índice primario disperso, que se utiliza para garantizar que los datos estén ordenados en disco, maximizando la compresión y evitando al mismo tiempo contaminar el índice primario y desperdiciar memoria.