Teste de codificações de compactação - Amazon Redshift
Exemplo

Teste de codificações de compactação

Se você decidir especificar codificações de coluna manualmente, talvez queira testar diferentes codificações com seus dados.

nota

Recomendamos que você use o comando COPY para carregar dados sempre que possível, permitindo que o comando COPY escolha as codificações ideais com base em seus dados. Como alternativa, você pode usar o comando ANALYZE COMPRESSION para visualizar as codificações sugeridas para os dados existentes. Para obter detalhes sobre a aplicação de compactação automática, consulte Carregamento de tabelas com compactação automática.

Para executar um teste significativo de compactação de dados, é necessário ter um grande número de linhas. Para este exemplo, criamos uma tabela e inserimos linhas usando uma instrução que seleciona a partir de duas tabelas; VENUE e LISTING. Deixamos de fora a cláusula WHERE que normalmente uniria as duas tabelas. O resultado é que cada linha da tabela VENUE é unida a todas as linhas da tabela LISTING, para um total de mais de 32 milhões de linhas. Isso é conhecido como uma junção cartesiana e não é normalmente recomendado. No entanto, para esta finalidade, é um método conveniente para criar muitas linhas. Se você tiver uma tabela existente com dados que deseja testar, poderá ignorar esta etapa.

Depois de termos uma tabela com dados de amostra, criamos uma tabela com sete colunas. Cada um tem uma codificação de compactação diferente: raw, bytedict, lzo, run length, text255, text32k e zstd. Preenchemos cada coluna com exatamente os mesmos dados, executando um comando INSERT que seleciona os dados da primeira tabela.

Para testar codificações de compactação, faça o seguinte:

  1. (Opcional) Primeiro, use uma junção cartesiana para criar uma tabela com um grande número de linhas. Ignore esta etapa se você deseja testar uma tabela existente. 

    create table cartesian_venue(
venueid smallint not null distkey sortkey,
venuename varchar(100),
venuecity varchar(30),
venuestate char(2),
venueseats integer);

insert into cartesian_venue
select venueid, venuename, venuecity, venuestate, venueseats
from venue, listing;

  2. Em seguida, crie uma tabela com as codificações que deseja comparar. 

    create table encodingvenue (
venueraw varchar(100) encode raw,
venuebytedict varchar(100) encode bytedict,
venuelzo varchar(100) encode lzo,
venuerunlength varchar(100) encode runlength,
venuetext255 varchar(100) encode text255,
venuetext32k varchar(100) encode text32k,
venuezstd varchar(100) encode zstd);

  3. Insira os mesmos dados em todas as colunas usando uma instrução INSERT com uma cláusula SELECT. 

    insert into encodingvenue
select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as  venuetext32k, venuename as  venuetext255, venuename as venuezstd
from cartesian_venue;

  4. Verifique o número de linhas na nova tabela. 

    select count(*) from encodingvenue

  count
----------
 38884394
(1 row)

  5. Consulte a tabela de sistema STV_BLOCKLIST para comparar o número de blocos de disco de 1 MB usados por cada coluna.

    A função de agregação MAX retorna o número de bloco mais alto para cada coluna. A tabela STV_BLOCKLIST inclui detalhes para as três colunas geradas pelo sistema. Este exemplo usa col < 6 na cláusula WHERE para excluir as colunas geradas pelo sistema. 

    select col, max(blocknum)
from stv_blocklist b, stv_tbl_perm p
where (b.tbl=p.id) and name ='encodingvenue'
and col < 7
group by name, col
order by col;

    A consulta retorna os seguintes resultados. As colunas são numeradas a partir de zero. Dependendo de como seu cluster está configurado, o resultado pode ter números diferentes, mas os tamanhos relativos devem ser similares. Você pode ver que a codificação BYTEDICT na segunda coluna produziu os melhores resultados para este conjunto de dados. Essa abordagem tem uma taxa de compactação de melhor que 20:1. As codificações LZO e ZSTD também produziram excelentes resultados. É evidente que diferentes conjuntos de dados produzem resultados diferentes. Quando uma coluna contém strings de texto mais longas, a codificação LZO frequentemente produz os melhores resultados de compactação.

     col | max
-----+-----
   0 | 203
   1 |  10
   2 |  22
   3 | 204
   4 |  56
   5 |  72
   6 |  20
(7 rows)

Se você tiver dados em uma tabela existente, será possível usar o comando ANALYZE COMPRESSION para visualizar as codificações sugeridas para a tabela. Por exemplo, o seguinte exemplo mostra a codificação recomendada para uma cópia da tabela VENUE, CARTESIAN_VENUE, que contém 38 milhões de linhas. Observe que ANALYZE COMPRESSION recomenda a codificação LZO para a coluna VENUENAME. ANALYZE COMPRESSION escolhe a compactação ideal com base em diversos fatores, incluindo a porcentagem de redução. Neste caso específico, BYTEDICT fornece a melhor compactação, mas LZO também produz uma compactação maior que 90 por cento. 

analyze compression cartesian_venue;

Table          | Column     | Encoding | Est_reduction_pct
---------------+------------+----------+------------------
reallybigvenue | venueid    | lzo      | 97.54            
reallybigvenue | venuename  | lzo      | 91.71            
reallybigvenue | venuecity  | lzo      | 96.01            
reallybigvenue | venuestate | lzo      | 97.68            
reallybigvenue | venueseats | lzo      | 98.21

Exemplo

O seguinte exemplo cria uma tabela CUSTOMER que tem colunas com vários tipos de dados. Esta instrução CREATE TABLE mostra uma das muitas combinações possíveis de codificações para essas colunas. 

create table customer(
custkey int encode delta,
custname varchar(30) encode raw,
gender varchar(7) encode text255,
address varchar(200) encode text255,
city varchar(30) encode text255,
state char(2) encode raw,
zipcode char(5) encode bytedict,
start_date date encode delta32k);

A tabela a seguir mostra as codificações de coluna que foram escolhidas para a tabela CUSTOMER, fornecendo uma explicação para as escolhas:

Coluna Tipo de dados Codificação Explicação
CUSTKEY int delta CUSTKEY consiste em valores inteiros consecutivos exclusivos. Como as diferenças são de um byte, DELTA é uma boa escolha.
CUSTNAME varchar(30) bruto CUSTNAME tem um grande domínio com poucos valores repetidos. Qualquer codificação de compactação seria provavelmente ineficaz.
GENDER varchar(7) text255 GENDER é um domínio muito pequeno com muitos valores repetidos. Text255 funciona perfeitamente com colunas VARCHAR nas quais as mesmas palavras se repetem.
ADDRESS varchar(200) text255 ADDRESS é um grande domínio, mas contém muitas palavras repetidas, como rua, avenida, Norte, Sul etc. Text 255 e text 32k são úteis para a compactação de colunas VARCHAR nas quais as mesmas palavras se repetem. O tamanho de coluna é curto, portanto text255 é uma boa escolha.
CITY varchar(30) text255 CITY é um grande domínio, com alguns valores repetidos. Determinados nomes de cidade são usados muito mais comumente do que outros. Text255 é uma boa escolha pelos mesmos motivos que ADDRESS.
STATE char(2) bruto Nos Estados Unidos, STATE é um domínio preciso de 50 valores de dois caracteres. A codificação Bytedict produziria alguma compactação, mas como o tamanho da coluna é de somente dois caracteres, a compactação pode não compensar o custo da descompactação dos dados.
ZIPCODE char(5) bytedict ZIPCODE é um domínio conhecido de pouco mais que 50.000 valores exclusivos. Determinados códigos postais ocorrem muito mais comumente do que outros. A codificação bytedict é muito eficaz quando uma coluna contém um número limitado de valores exclusivos.
START_DATE date delta32k Codificações delta são muito úteis para colunas de data e hora, especialmente se as linhas são carregadas em ordem de data.