

 O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

# Práticas recomendadas do Amazon Redshift para projetar tabelas
<a name="c_designing-tables-best-practices"></a>

À medida que você planeja seu banco de dados, certas decisões fundamentais relativas ao planejamento da tabela influenciarão fortemente a performance geral de consultas. Essas escolhas de design também têm um efeito significativo nos requisitos de armazenamento, que afetam a performance da consulta ao reduzir o número de operações de E/S e minimizar a memória necessária para processar consultas.

Nesta seção, você encontra um resumo das decisões de planejamento mais importantes e práticas recomendadas para otimizar a performance de consultas. O [Otimização automática de tabelas](t_Creating_tables.md) fornece explicações mais detalhadas e exemplos de opções de design de tabela.

**Topics**
+ [Escolha a melhor chave de classificação](c_best-practices-sort-key.md)
+ [Escolha o melhor estilo de distribuição](c_best-practices-best-dist-key.md)
+ [Permitir que COPY selecione as codificações de compactação](c_best-practices-use-auto-compression.md)
+ [Definição das limitações da chave primária e chave estrangeira](c_best-practices-defining-constraints.md)
+ [Uso do menor tamanho possível de coluna](c_best-practices-smallest-column-size.md)
+ [Uso dos tipos de dados de data/hora para colunas de data](c_best-practices-timestamp-date-columns.md)

# Escolha a melhor chave de classificação
<a name="c_best-practices-sort-key"></a>

O Amazon Redshift armazena seus dados no disco em ordem classificada de acordo com a chave de classificação. O otimizador de consulta Amazon Redshift usa a ordem de classificação quando determina os planos de consulta ideais. 

**nota**  
Ao usar a otimização automática de tabela, você não precisa escolher a chave de classificação de sua tabela. Para obter mais informações, consulte [Otimização automática de tabelas](t_Creating_tables.md).

Seguem algumas sugestões para a melhor abordagem:
+ Para que o Amazon Redshift escolha a ordem de classificação apropriada, especifique `AUTO` para a chave de classificação. 
+ Se dados recentes forem mais consultados, especifique a coluna de time stamp como a coluna principal da chave de classificação. 

  As consultas são mais eficientes, pois podem ignorar blocos inteiros que estão fora do período.
+ Se você fizer filtragem de intervalos frequentes ou filtragem de igualdade em uma coluna, especifique esta coluna como a chave de classificação. 

   O Amazon Redshift pode ignorar a leitura de blocos inteiros de dados para essa coluna. É possível fazer isso, pois ele rastreia os valores mínimo e máximo da coluna armazenados em cada bloco e pode ignorar blocos que não se aplicam ao intervalo previsto.
+ Se você costuma ingressar em uma tabela, especifique a coluna de união como a chave de classificação e a chave de distribuição. 

  Isso permite que o otimizador de consulta escolha uma junção de mesclagem de classificação em vez de uma junção hash mais lenta. Como os dados já são classificados na chave de junção, o otimizador de consulta pode ignorar a fase de classificação da junção de mesclagem de classificação.

# Escolha o melhor estilo de distribuição
<a name="c_best-practices-best-dist-key"></a>

Quando você executa uma consulta, o otimizador de consulta redistribui as linhas aos nós de computação conforme necessário para executar junções e agregações. O objetivo da seleção de um estilo de distribuição da tabela é minimizar o impacto da etapa de redistribuição colocando os dados no local em que eles precisam estar antes que a consulta seja executada. 

**nota**  
Quando você usa a otimização automática de tabelas, não é necessário escolher o estilo de distribuição da tabela. Para obter mais informações, consulte [Otimização automática de tabelas](t_Creating_tables.md).

Seguem algumas sugestões para a melhor abordagem:

1. Distribuir a tabela de fatos e uma tabela de dimensões nas colunas comuns.

   Sua tabela de fatos pode ter apenas uma chave de distribuição. Qualquer tabela que ingressar em outra chave não é disposta com a tabela de fatos. Escolha uma dimensão para disposição com base na frequência em que ela é ingressada e no tamanho das linhas de junção. Designe a chave primária da tabela de dimensões e a chave estrangeira correspondente da tabela de fatos como a DISTKEY. 

1. Escolha a maior dimensão com base no tamanho do conjunto de dados filtrado. 

   Como somente as linhas que são usadas na junção precisam ser distribuídas, considere o tamanho do conjunto de dados após a filtragem e não apenas o tamanho da tabela. 

1. Escolha uma coluna com alta cardinalidade no conjunto de resultados filtrados. 

   Se você distribui uma tabela de vendas em uma coluna de data, por exemplo, provavelmente você obterá uma distribuição de dados razoavelmente uniforme, a não ser que a maioria de suas vendas sejam sazonais. Entretanto, se você usa um predicado restrito por intervalo para filtrar um período de data curto, a maioria das linhas filtradas ocorrem em um conjunto limitado de fatias e o workload da consulta é distorcido. 

1. Alterar algumas tabelas de dimensões para usar a distribuição ALL.

   Se uma tabela de dimensão não pode ser disposta com a tabela de fato ou outras tabelas de junção importantes, você pode melhorar a performance da consulta significativamente ao distribuir toda a tabela para todos os nós. O uso de distribuição ALL multiplica as exigências de espaço de armazenamento e aumenta os tempos de carregamento e operações de manutenção, portanto você deve considerar todos os fatores antes de optar pela distribuição ALL.

Para que o Amazon Redshift escolha o estilo de distribuição apropriado, especifique `AUTO` para o estilo de distribuição. 

Para obter mais informações sobre a escolha de estilos de distribuição, consulte [Distribuição de dados para otimização de consultas](t_Distributing_data.md).

# Permitir que COPY selecione as codificações de compactação
<a name="c_best-practices-use-auto-compression"></a>

Você pode especificar codificações de compactação ao criar uma tabela mas, na maioria dos casos, a compactação automática produz os melhores resultados.

ENCODE AUTO é o padrão para tabelas. Quando a tabela é definida como ENCODE AUTO, o Amazon Redshift gerencia automaticamente a codificação de compactação para todas as colunas da tabela. Para obter mais informações, consulte [CRIAR TABELA](r_CREATE_TABLE_NEW.md) e [ALTER TABLE](r_ALTER_TABLE.md).

O comando COPY analisa seus dados e aplica codificações de compactação em uma tabela vazia automaticamente como parte da operação de carregamento. 

A compactação automática equilibra a performance geral ao escolher codificações de compactação. As varreduras restritas por intervalo podem apresentar má performance se as colunas de chaves de classificação forem mais altamente compactadas do que outras colunas na mesma consulta. Como resultado, a compactação automática escolhe uma codificação menos eficiente para manter as colunas de chaves de classificação equilibradas com outras colunas.

Suponha que a chave de classificação da sua tabela seja uma data ou um time stamp e que a tabela use colunas varchar muito grandes. Nesse caso, você pode obter melhor performance descompactando a coluna de chave de classificação. Execute o comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) na tabela e use as codificações para criar uma nova tabela, mas omita a codificação de compactação para a chave de classificação.

Há um custo de performance pela codificação de compactação automática, mas apenas se a tabela estiver vazia e ainda não tiver codificação de compactação. Para tabelas de vida curta e tabelas que você cria com frequência, como tabelas de preparação, carregue a tabela uma vez com compactação automática ou execute o comando ANALYZE COMPRESSION. Em seguida, use essas codificações para criar novas tabelas. Você pode adicionar as codificações à instrução CRIAR TABELA ou usar CRIAR TABELA COMO para criar uma nova tabela com a mesma codificação. 

Para obter mais informações, consulte [Carregamento de tabelas com compactação automática](c_Loading_tables_auto_compress.md).

# Definição das limitações da chave primária e chave estrangeira
<a name="c_best-practices-defining-constraints"></a>

Defina as limitações da chave primária e estrangeira entre as tabelas sempre que apropriado. Embora elas sejam apenas informativas, o otimizador de consulta utiliza estas limitações para gerar planos de consulta mais eficientes.

Não defina limitações para a chave primária e chave estrangeira a menos que sua aplicação exija as limitações. O Amazon Redshift não impõe limitações exclusivas para a chave primária e chave estrangeira. 

Consulte [Restrições de tabela](t_Defining_constraints.md) para obter mais informações sobre como o Amazon Redshift usa limitações.

# Uso do menor tamanho possível de coluna
<a name="c_best-practices-smallest-column-size"></a>

Não crie o hábito de usar o tamanho máximo de coluna por conveniência. 

Em vez disso, considere os maiores valores que você provavelmente armazenará nas colunas e dimensione-as de acordo. Por exemplo, uma coluna CHAR para armazenar abreviações de estados e territórios dos EUA usada pelos correios só precisa ser CHAR(2).

# Uso dos tipos de dados de data/hora para colunas de data
<a name="c_best-practices-timestamp-date-columns"></a>

O Amazon Redshift armazena dados DATE e TIMESTAMP com mais eficiência do que CHAR ou VARCHAR, o que resulta em melhor performance de consulta. Use o tipo de dados DATA ou DATA/HORA, dependendo da solução necessária, em vez de um tipo de caractere ao armazenar informações de data/hora. Para obter mais informações, consulte [Tipos de datetime](r_Datetime_types.md).