Guia de tradução de SQL do Amazon Redshift

Quem move dados entre o ClickHouse e o Redshift percebe imediatamente que o ClickHouse oferece uma variedade maior de tipos, além de ser menos restritivo. Enquanto o Redshift exige que os usuários especifiquem possíveis comprimentos de string, mesmo quando variáveis, o ClickHouse elimina essa restrição e essa complexidade ao armazenar strings como bytes, sem codificação. Assim, o tipo String do ClickHouse não tem limites nem exige especificação de comprimento.

Além disso, você pode aproveitar Arrays, Tuples e Enums — ausentes no Redshift como tipos de primeira classe (embora Arrays/Structs possam ser simulados com SUPER) —, uma limitação que costuma frustrar os usuários. O ClickHouse também permite persistir estados de agregação, seja em tempo de consulta ou até mesmo em uma tabela. Isso permite pré-agregar os dados, normalmente usando uma visão materializada, e pode melhorar drasticamente o desempenho das consultas mais comuns.

Abaixo, mapeamos o tipo equivalente no ClickHouse para cada tipo do Redshift:

Tanto o ClickHouse quanto o Redshift têm o conceito de “chave de ordenação”, que determina como os dados são ordenados ao serem armazenados. O Redshift define a chave de ordenação usando a cláusula SORTKEY:

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

Em comparação, o ClickHouse usa a cláusula ORDER BY para especificar a ordem de ordenação:

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

Na maioria dos casos, você pode usar no ClickHouse as mesmas colunas e a mesma ordem da chave de ordenação do Redshift, supondo que esteja usando o tipo COMPOUND padrão. Quando os dados são adicionados ao Redshift, você deve executar os comandos VACUUM e ANALYZE para reordenar os dados recém-adicionados e atualizar as estatísticas do planejador de consultas — caso contrário, o espaço não ordenado aumenta. Nenhum processo desse tipo é necessário no ClickHouse.

O Redshift oferece alguns recursos práticos para chaves de ordenação. O primeiro são as chaves de ordenação automáticas (usando SORTKEY AUTO). Embora isso possa ser adequado para começar, chaves de ordenação explícitas garantem o melhor desempenho e a melhor eficiência de armazenamento quando a chave de ordenação é ideal. O segundo é a chave de ordenação INTERLEAVED, que atribui o mesmo peso a um subconjunto de colunas na chave de ordenação para melhorar o desempenho quando uma consulta usa uma ou mais colunas de ordenação secundárias. O ClickHouse oferece projeções explícitas, que alcançam o mesmo resultado final com uma configuração um pouco diferente.

Você deve estar ciente de que o conceito de “chave primária” representa coisas diferentes no ClickHouse e no Redshift. No Redshift, a chave primária se assemelha ao conceito tradicional de SGBD, destinado a impor restrições. No entanto, elas não são estritamente aplicadas no Redshift e, em vez disso, atuam como dicas para o planejador de consultas e para a distribuição de dados entre os nós. No ClickHouse, a chave primária denota colunas usadas para construir o índice primário esparso, usado para garantir que os dados sejam ordenados em disco, maximizando a compactação e evitando sobrecarregar o índice primário e desperdiçar memória.