Práticas recomendadas para tabelas híbridas¶

Desempenho da consulta no Snowsight em comparação com o acesso baseado em driver¶

O Snowsight oferece acesso avançado a planos de consulta, estatísticas de dados, histórico de consultas e outras informações detalhadas que são úteis para prototipagem interativa de consultas, depuração, investigação, monitoramento e outras atividades. O fornecimento dessa rica experiência interativa adiciona sobrecarga ao mecanismo de consulta do Snowflake. Dessa forma, a latência de consultas de curta duração executadas pelo Snowsight não é indicativa do desempenho que pode ser obtido com drivers programáticos. As consultas executadas por meio de soluções baseadas em código ou em driver são executadas com menor latência e variabilidade do que as consultas executadas por meio do Snowsight.

Drivers de cliente para tabelas híbridas¶

Para acessar tabelas híbridas, você precisará usar uma das seguintes versões de driver:

Driver	Versão mínima
Go	1.6.25
JDBC	3.13.31
.Net	2.1.2
Node.js	1.9.0
ODBC	3.0.2
PHP	2.0.0
Conector Python	3.1.0
SnowSQL	1.2.28

Nota

Talvez você não consiga acessar tabelas híbridas usando uma versão anterior do driver.

Para obter o melhor desempenho com tabelas híbridas, certifique-se de usar a versão mais recente do driver selecionado.

Você também pode acessar tabelas híbridas usando o API de SQL do Snowflake; no entanto, essa API não é recomendada para casos de uso que exigem latência ideal.

Configuração do cliente e métodos de acesso¶

O gerenciamento de conexão afeta diretamente o desempenho e a escalabilidade. Ao se conectar a bancos de dados que contêm tabelas híbridas, considere as seguintes práticas recomendadas para obter um bom desempenho.

• Use o pool de conexões com conexões de longa duração para eliminar a sobrecarga de estabelecer repetidamente novas conexões. A maioria das estruturas de cliente que se conectam ao Snowflake fornece um mecanismo de pool de conexões para gerenciar o acesso com eficiência.

• A proximidade da rede afeta significativamente a latência de ponta a ponta; portanto, coloque seu software cliente na mesma região de nuvem que a conta Snowflake.

• Use instruções preparadas com parâmetros vinculados para que o planejador de consultas reutilize planos de consultas criados anteriormente.

• Use os drivers de cliente programáticos compatíveis, e não o Snowsight, para obter a latência ideal. Consulte Drivers de cliente para tabelas híbridas.

Design e uso de índice¶

A criação e o uso de índices é um componente essencial para obter o desempenho ideal das tabelas híbridas. Considere as seguintes recomendações:

• Criar índices secundários para predicados usados com frequência.

• Projetar índices compostos para corresponder a padrões de consulta completos.

• Evitar o uso de vários índices com colunas na mesma posição ordinal.

• Entender a cardinalidade de seus dados antes de criar índices. Os índices criados com uma única coluna de baixa cardinalidade têm benefícios limitados. Consulte Estimativa do número de valores distintos.

• Os índices aumentam a sobrecarga de gravação e os requisitos de armazenamento. Tenha o cuidado de equilibrar o desempenho de leitura e gravação para aplicativos que exigem operações de gravação de baixa latência.

Índices adequadamente projetados melhoram significativamente o desempenho das consultas, fornecendo caminhos eficientes de acesso aos dados. Se possível, escolha chaves primárias para obter a seletividade ideal e, ao mesmo tempo, minimizar a complexidade. Em alguns casos, adicionar colunas com valores de chave alternativa ou calculados proporciona melhor desempenho do que índices compostos complexos. Os índices secundários melhoram drasticamente o desempenho das colunas acessadas com frequência.

Para consultas bem definidas, usar a palavra-chave INCLUDE para adicionar colunas a um índice ao criar a tabela pode diminuir ainda mais a latência. Consulte Crie um índice secundário com uma coluna INCLUDE.

CREATE OR REPLACE HYBRID TABLE icecream_orders (
  id NUMBER PRIMARY KEY AUTOINCREMENT START 1 INCREMENT 1 ORDER,
  store_id NUMBER NOT NULL,
  flavor VARCHAR(20) NOT NULL,
  order_ts TIMESTAMP_NTZ,
  num_scoops NUMERIC,
  INDEX idx_icecream_order_store (store_id, order_ts),
  INDEX idx_icecream_timestamp (order_ts)
  );

-- Generate sample data for testing

INSERT INTO icecream_orders (store_id, flavor, order_ts, num_scoops)
  SELECT
    UNIFORM(1, 10, RANDOM()),
    ARRAY_CONSTRUCT('CHOCOLATE', 'VANILLA', 'STRAWBERRY', 'LEMON')[UNIFORM(0, 3, RANDOM())],
    DATEADD(SECOND, UNIFORM(0, 86400, RANDOM()), DATEADD(DAY, UNIFORM(-90, 0, RANDOM()), CURRENT_DATE())),
    UNIFORM(1, 3, RANDOM())
  FROM TABLE(GENERATOR(ROWCOUNT => 10000))
  ;

-- Use idx_icecream_order_store (first column)

  SELECT *
    FROM icecream_orders
    WHERE store_id = 5;

-- Use idx_icecream_order_store (both columns)

  SELECT *
    FROM icecream_orders
    WHERE store_id IN (1,2,3) AND order_ts > DATEADD(DAY, -7, CURRENT_DATE());

-- Use idx_icecream_timestamp

  SELECT *
    FROM icecream_orders
    WHERE order_ts BETWEEN DATEADD(DAY, -2, CURRENT_DATE()) AND DATEADD(DAY, -2, CURRENT_DATE());

Carregamento de dados em massa¶

Você pode usar várias otimizações e práticas recomendadas para carregar dados em tabelas híbridas:

• Use CREATE TABLE … AS SELECT (também chamado de CTAS) para criar e carregar imediatamente tabelas vazias.

• Verifique o uso de carregamento em massa otimizado em perfis de consulta.

• Prefira o carregamento de dados inicial como uma única transação em massa.

As tabelas híbridas oferecem um caminho otimizado de carregamento em massa que proporciona um desempenho de carregamento até 10 vezes mais rápido do que os métodos de carregamento padrão. Esse caminho otimizado de carregamento em massa é aplicado automaticamente quando você carrega dados em uma tabela vazia usando os comandos CTAS (CREATE TABLE AS SELECT), COPY INTO ou INSERT INTO SELECT. (Uma tabela vazia é uma tabela que nunca conteve nenhum dado)

É possível verificar se a otimização está sendo usada verificando a seção de estatísticas do perfil de consulta, onde as linhas serão relatadas como Number of rows bulk loaded em vez de Number of rows inserted.

Para tabelas que já contêm dados, o caminho otimizado de carregamento em massa não está disponível no momento. Nesses casos, as operações de carregamento podem atingir aproximadamente 1 milhão de registros por minuto, embora isso varie de acordo com o tamanho do registro, a estrutura da tabela e o número de índices.

Otimização de warehouse¶

Um warehouse de tamanho X-Small é suficiente para muitas cargas de trabalho operacionais. Para obter maior simultaneidade e taxa de transferência em consultas operacionais de execução curta, aumente o número de nós de computação usando um warehouse multicluster em vez de aumentar os recursos de computação com um warehouse maior.

Se a sua carga de trabalho tiver padrões de produção variáveis, você poderá ativar o escalonamento automático para reduzir o consumo quando a demanda for menor. Defina a política de dimensionamento como Standard em vez de Economy para obter o melhor desempenho e eficiência em cargas de trabalho que exigem alta taxa de transferência ou baixa latência. Para obter mais informações, consulte Como definir a política de escalonamento para um warehouse multicluster.

Em alguns casos, isolar as cargas de trabalho em warehouses separados pode ser benéfico para permitir o dimensionamento independente. Se você tiver uma carga de trabalho híbrida mista com componentes operacionais e analíticos, será vantajoso separar os componentes operacionais e analíticos em warehouses diferentes. Se não for possível separá-los e for necessário executá-los juntos no mesmo warehouse, escolha o tamanho do warehouse com base nos requisitos de latência da consulta analítica e escolha a contagem de nós de vários clusters com base no que é necessário para oferecer suporte à taxa de transferência da carga de trabalho.

Armazenamento em cache e aquecimento¶

A primeira consulta de tabela híbrida emitida para um warehouse recém-iniciado aciona atividades como planejamento de consultas, seleção de índices, E/S para carregar dados, decisões de cache e, é claro, execução de consultas. O mecanismo de consulta continua otimizando a memória e o armazenamento para a consulta. Esse tempo é chamado de período de “aquecimento”. A latência de consulta cai até o mecanismo convergir para uma latência de estado estável.

• Use warehouses dedicados para cargas de trabalho de tabelas híbridas para evitar interferência no cache.

• Entenda que atingir a latência de estado estável leva de vários segundos a 2 a 3 minutos à medida que o cache se aquece.

• Configure a suspensão automática e o dimensionamento automático para equilibrar a eficiência e o aquecimento do cache.

As tabelas híbridas utilizam várias abordagens de cache para otimizar o desempenho. O cache de plano reduz a sobrecarga de compilação ao armazenar planos de consulta usados com frequência. O cache de dados do armazenamento de colunas mantém os dados acessados com frequência na memória, e o cache de metadados fornece acesso rápido às informações da tabela e do índice. As tabelas híbridas não usam um cache de resultado.

Esses caches requerem algum tempo para serem otimizados de acordo com seus padrões de carga de trabalho. O uso de warehouses dedicados para cargas de trabalho de tabelas híbridas evita a interferência do cache de outras cargas de trabalho. As consultas iniciais após uma inicialização a frio apresentam maior latência até que os caches sejam preenchidos. Se a sua carga de trabalho tiver padrões de taxa de transferência variáveis, você poderá ativar o dimensionamento automático e a suspensão automática para reduzir o consumo ou suspender o warehouse quando a demanda for menor. Quando o warehouse for reiniciado ou dimensionado automaticamente para adicionar um novo cluster, os caches precisarão ser reidratados. Para obter o melhor desempenho, defina a política de dimensionamento como Standard em vez de Economy. Consulte Warehouses multicluster.

Procedimentos armazenados e tabelas híbridas¶

Os procedimentos armazenados são aceitos para tabelas híbridas; no entanto, a execução de transações com AUTOCOMMIT habilitado ou transações com várias instruções oferece um melhor desempenho e eficiência do que chamar um procedimento armazenado.

Tarefas sem servidor e tabelas híbridas¶

Embora tarefas sem servidor sejam aceitas, esteja ciente de que você pode não ter desempenho ou eficiência ideais para cargas de trabalho que usam tabelas híbridas.

Monitoramento de desempenho¶

A exibição recomendada para o monitoramento do desempenho da tabela híbrida é a Exibição AGGREGATE_QUERY_HISTORY. Essa exibição contém detalhes de execução de consultas agregados em um curto período de tempo.

Por exemplo, para recuperar o desempenho médio do intervalo padrão nas últimas 24 horas para um warehouse que atende a solicitações de tabelas híbridas:

SELECT *
  FROM SNOWFLAKE.ACCOUNT_USAGE.AGGREGATE_QUERY_HISTORY
  WHERE warehouse_name = 'HYBRID_TABLES_WAREHOUSE'
  AND query_type = 'SELECT'
  AND interval_start_time >= DATEADD(hour, -24, CURRENT_TIMESTAMP());

Consulte a Exibição AGGREGATE_QUERY_HISTORY para obter mais exemplos.

Monitoramento de cotas e limitação¶

As tabelas híbridas implementam controles de cota no nível da conta tanto para o armazenamento híbrido quanto para a taxa de transferência de solicitações de tabelas híbridas. Essas cotas garantem um desempenho consistente para todos os usuários. As cotas padrão são suficientes para a maioria das implementações iniciais, mas podem precisar de ajustes à medida que as cargas de trabalho aumentam.

• Monitore a cota de solicitações da tabela híbrida usando a Exibição AGGREGATE_QUERY_HISTORY.

• Monitore a cota de armazenamento híbrido usando a Exibição STORAGE_USAGE.

• Altas porcentagens de limitação nos perfis de consulta indicam que você está se aproximando dos limites da taxa de transferência. Quando você utilizar consistentemente mais de 70% de qualquer uma das cotas, solicite proativamente um aumento por meio do suporte Snowflake.

O desempenho das tabelas híbridas está sujeito à limitação, mesmo em um caso em que o uso da computação de warehouse virtual não seja alto. Para monitorar seu uso e determinar se uma tabela híbrida está tendo seu fluxo controlado, consulte o exemplo em Exibição AGGREGATE_QUERY_HISTORY. Você também pode recuperar o número de solicitações de tabela híbrida limitadas na coluna HYBRID_TABLE_REQUESTS_THROTTLED_COUNT.

Para obter mais informações, consulte Cotas e limitação.

Solução de problemas de desempenho¶

Se você não estiver atingindo o desempenho esperado depois de implementar essas práticas recomendadas, o suporte Snowflake pode ajudar a analisar e otimizar sua implementação. Ao criar um caso de suporte, inclua as seguintes informações para permitir uma resolução rápida:

• IDs de consulta (UUIDs) para consultas representativas que mostram desempenho abaixo do ideal

• Características da carga de trabalho:

  • Padrões típicos de consulta

  • Latência esperada versus latência real

  • Requisitos de simultaneidade

  • Volumes de armazenamento de dados

  • Tamanho da linha da resposta da consulta

  • Coluna de estimativas de cardinalidade

• Qualquer alteração recente nos esquemas de tabela, índices ou padrões de carga de trabalho

• Métricas de limitação de perfis de consulta

• Diferenças de desempenho entre warehouses frios e quentes

Inclua exemplos rápidos e lentos de consultas semelhantes, se possível, para ajudar a identificar oportunidades de otimização. Essa comparação ajuda as equipes de suporte a identificar rapidamente possíveis melhorias na configuração ou no design.