Meilleures pratiques pour les tables hybrides¶

Performance des requêtes dans Snowsight par rapport à l’accès par pilote¶

Snowsight offre un accès étendu aux plans de requête, aux statistiques sur les données, à l’historique des requêtes et à d’autres informations détaillées utiles pour le prototypage interactif de requêtes, le débogage, l’investigation, la surveillance et d’autres activités. Cette expérience interactive riche constitue une charge supplémentaire pour le moteur de requête de Snowflake. Ainsi, le temps de latence pour les requêtes de courte durée exécutées via Snowsight n’est pas représentatif des performances qui peuvent être atteintes avec des pilotes programmatiques. Les requêtes exécutées via des solutions orientées code ou pilotes présentent une latence et une variabilité moindres que les requêtes exécutées via Snowsight.

Pilotes client des tables hybrides¶

Pour accéder aux tables hybrides, vous devez utiliser l’une des versions de pilote suivantes :

Pilote	Version minimale
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
Connecteur Python	3.1.0
SnowSQL	1.2.28

Note

Il se peut que vous ne puissiez pas accéder aux tables hybrides en utilisant une version antérieure du pilote.

Pour des performances optimales avec les tables hybrides, veillez à utiliser la dernière version du pilote sélectionné.

Vous pouvez également accéder aux tables hybrides en utilisant API SQL Snowflake ; toutefois, cette API n’est pas recommandée pour les cas d’utilisation nécessitant une optimisation de la latence.

Configuration du client et méthodes d’accès¶

La gestion des connexions a une incidence directe sur les performances et l’évolutivité. Lorsque vous vous connectez à des bases de données contenant des tables hybrides, tenez compte des meilleures pratiques suivantes pour obtenir de bonnes performances.

• Utilisez le pooling de connexions avec des connexions à longue durée de vie pour éliminer les surcoûts liés à l’établissement répété de nouvelles connexions. La plupart des frameworks clients qui se connectent à Snowflake fournissent un mécanisme de pooling de connexions pour gérer efficacement l’accès.

• La proximité du réseau affecte de manière significative la latence de bout en bout. Veillez par conséquent à colocaliser votre logiciel client dans la même région Cloud que le compte Snowflake.

• Utilisez des instructions préparées avec des paramètres liés pour que le planificateur de requêtes réutilise les plans de requête créés précédemment.

• Utilisez les pilotes clients programmatiques pris en charge, et non Snowsight, pour obtenir une latence optimale. Voir Pilotes client des tables hybrides.

Conception et utilisation des index¶

La création et l’utilisation d’index sont un élément clé de l’optimisation des performances des tables hybrides. Prenez en considération les recommandations suivantes :

• Créez des index secondaires pour les prédicats fréquemment utilisés.

• Concevez des index composites correspondant à des modèles de requêtes complets.

• Évitez d’utiliser plusieurs index pour des colonnes ayant la même position ordinale.

• Tenez compte de la cardinalité de vos données pour créer des index. Les index construits à partir d’une seule colonne de faible cardinalité présentent un intérêt limité. Voir Le nombre de valeurs distinctes..

• Les index augmentent la charge de travail d’écriture et les exigences en matière de stockage. Veillez à équilibrer les performances de lecture et d’écriture pour les applications qui requièrent des opérations d’écriture à faible latence.

Des index bien conçus améliorent considérablement les performances des requêtes en fournissant des chemins d’accès efficaces aux données. Si possible, choisissez des clés primaires pour une sélectivité optimale tout en minimisant la complexité. Dans certains cas, l’ajout de colonnes comportant des valeurs de clés calculées ou artificielles permet d’obtenir de meilleures performances que des index composites complexes. Les index secondaires améliorent considérablement les performances des colonnes à accès fréquents.

Pour des requêtes bien définies, l’utilisation du mot-clé INCLUDE pour ajouter des colonnes à un index lors de la création de la table peut encore réduire le temps de latence. Voir Créer un index secondaire avec une colonne 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());

Chargement de données en masse¶

Vous pouvez recourir à plusieurs optimisations et meilleures pratiques pour charger les données dans les tables hybrides :

• Utilisez CREATE TABLE … AS SELECT (également appelé CTAS) pour créer et charger immédiatement des tables vides.

• Vérifiez que le chargement en masse optimisé est utilisé dans les profils de requête.

• Préférez le chargement initial des données en une seule transaction de masse.

Les tables hybrides offrent un chemin de chargement en masse optimisé qui permet d’obtenir des performances de chargement jusqu’à 10 fois supérieures à celles des méthodes de chargement standard. Ce chemin optimisé pour le chargement en masse est automatiquement appliqué lorsque vous chargez des données dans une table vide à l’aide des commandes CTAS (CREATE TABLE AS SELECT), COPY INTO ou INSERT INTO SELECT. (Une table vide est une table qui n’a jamais contenu de données)

Vous pouvez vérifier que l’optimisation est utilisée en consultant la section des statistiques du profil de la requête, où les lignes seront signalées comme Number of rows bulk loaded plutôt que Number of rows inserted.

Pour les tables qui contiennent déjà des données, le chemin optimisé pour le chargement en masse n’est pas disponible actuellement. Dans ces cas, les opérations de chargement peuvent atteindre environ 1 million d’enregistrements par minute, bien que ce chiffre varie en fonction de la taille des enregistrements, de la structure de la table et du nombre d’index.

Optimisation de l’entrepôt¶

Un entrepôt de taille X-Small est suffisant pour de nombreuses opérations. Afin d’atteindre une concurrence et un débit plus élevés pour les requêtes opérationnelles de courte durée, augmentez le nombre de nœuds de calcul en utilisant un entrepôt multicluster plutôt qu’en augmentant les ressources de calcul avec un entrepôt plus grand.

Si votre charge de travail présente des profils de débit variables, vous pouvez activer le dimensionnement automatique pour réduire la consommation lorsque la demande est plus faible. Paramétrez la politique de mise à l’échelle sur Standard plutôt que sur Economy pour obtenir le meilleur niveau de performances et d’efficacité sur les charges de travail qui nécessitent un débit élevé ou une faible latence. Pour plus d’informations, voir Définition de la politique de mise à l’échelle d’un entrepôt multi-clusters.

Dans certains cas, il peut être utile d’isoler les charges de travail dans des entrepôts distincts pour permettre une mise à l’échelle indépendante. Si vous avez une charge de travail hybride mixte avec des composants opérationnels et analytiques, il est avantageux de séparer les composants opérationnels et analytiques en les plaçant dans des entrepôts différents. Si vous ne pouvez pas les séparer et que vous devez les exécuter ensemble sur le même entrepôt, choisissez la taille de l’entrepôt en fonction des exigences en matière de latence des requêtes analytiques et le nombre de nœuds multiclusters en fonction du nombre nécessaire pour prendre en charge le débit de votre charge de travail.

Mise en cache et échauffement¶

La première requête de table hybride émise vers un entrepôt récemment mis en service déclenche des activités telles que la planification de la requête, la sélection de l’index, les entrées/sorties pour charger les données, les décisions de mise en cache et, bien sûr, l’exécution de la requête. Le moteur de requête continue d’optimiser la mémoire et le stockage pour la requête. Cette période est appelée « période d’échauffement ». La latence des requêtes diminue jusqu’à ce que le moteur converge vers une latence stable.

• Utilisez des entrepôts dédiés pour les charges de travail des tables hybrides afin d’éviter les interférences avec le cache.

• Sachez que le temps de latence à l’état stable peut varier de quelques secondes à 2 ou 3 minutes, le temps que le cache se réchauffe.

• Configurez la suspension automatique et la mise à l’échelle automatique pour équilibrer l’efficacité et la chaleur du cache.

Les tables hybrides utilisent plusieurs approches de cache pour optimiser les performances. Le cache de plan réduit la charge de compilation en stockant les plans de requête fréquemment utilisés. Le cache de données du magasin de colonnes conserve en mémoire les données à accès fréquents, et le cache de métadonnées fournit un accès rapide aux informations sur les tables et les index. Les tables hybrides n’utilisent pas de cache de résultats.

L’optimisation de ces caches en fonction de vos modèles de charge de travail prend un certain temps. L’utilisation d’entrepôts dédiés pour les charges de travail des tables hybrides permet d’éviter les interférences entre le cache et les autres charges de travail. Les requêtes initiales après un démarrage à froid présentent un temps de latence plus élevé jusqu’à ce que les caches soient remplis. Si votre charge de travail présente des profils de débit variables, vous pouvez activer la mise à l’échelle automatique et la suspension automatique pour réduire la consommation ou suspendre votre entrepôt lorsque la demande est plus faible. Lorsque votre entrepôt redémarre ou procède à une mise à l’échelle automatique pour ajouter un nouveau cluster, les caches doivent se réhydrater. Paramétrez la politique de mise à l’échelle sur Standard plutôt que sur Economy pour obtenir de meilleures performances. Voir Entrepôts multi-clusters.

Procédures stockées et tables hybrides¶

Les procédures stockées sont prises en charge pour les tables hybrides. Cependant, l’exécution de transactions avec AUTOCOMMIT activé ou de transactions multi-instructions offre de meilleures performances et une plus grande efficacité que l’appel d’une procédure stockée.

Tâches sans serveur et tables hybrides¶

Bien que les tâches sans serveur soient prises en charge, sachez que vous risquez de ne pas bénéficier de performances ou d’une efficacité optimales pour les charges de travail qui utilisent des tables hybrides.

Suivi des performances¶

La vue recommandée pour le contrôle des performances des tables hybrides est la Vue AGGREGATE_QUERY_HISTORY. Cette vue contient les détails de l’exécution des requêtes agrégés sur une courte période.

Par exemple, pour récupérer la performance moyenne de l’intervalle par défaut au cours des 24 dernières heures pour un entrepôt servant des requêtes de tables hybrides :

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());

Voir la Vue AGGREGATE_QUERY_HISTORY pour plus d’exemples.

Surveillance des quotas et de la limitation¶

Les tables hybrides mettent en œuvre des contrôles de quotas au niveau du compte pour le stockage hybride et le débit des requêtes des table hybrides. Ces quotas garantissent des performances homogènes pour tous les utilisateurs. Les quotas par défaut sont suffisants pour la plupart des implémentations initiales, mais peuvent nécessiter des ajustements au fur et à mesure de l’augmentation de la charge de travail.

• Surveillez le quota de requêtes de la table hybride à l’aide de la Vue AGGREGATE_QUERY_HISTORY.

• Surveillez le quota de stockage hybride à l’aide de la Vue STORAGE_USAGE.

• Des pourcentages de limitation élevés dans les profils de requête indiquent que vous approchez des limites de débit. Lorsque vous utilisez régulièrement plus de 70 % de l’un ou l’autre quota, demandez une augmentation de manière proactive auprès du support Snowflake.

Les performances des tables hybrides sont soumises à une limitation, y compris dans le cas où l’utilisation de l’entrepôt virtuel n’est pas élevée. Pour surveiller votre utilisation et déterminer si une table hybride fait l’objet d’une limitation, reportez-vous à l’exemple présenté dans la Vue AGGREGATE_QUERY_HISTORY. Vous pouvez également récupérer le nombre de requêtes de tables hybrides limitées auprès de la colonne HYBRID_TABLE_REQUESTS_THROTTLED_COUNT.

Pour plus d’informations, voir Quotas et limitations.

Dépannage des problèmes de performance¶

Si vous n’obtenez pas les performances attendues après avoir mis en œuvre ces meilleures pratiques, le support Snowflake peut vous aider à analyser et à optimiser votre mise en œuvre. Lors de la création d’un ticket d’assistance, indiquez les informations suivantes pour permettre une résolution rapide du problème :

• ID de requête (UUID) des requêtes représentatives montrant une performance sous-optimale

• Caractéristiques de la charge de travail :

  • Modèles de requête typiques

  • Comparaison entre la latence prévue et la latence réelle

  • Exigences en matière de concurrence

  • Volumes de stockage de données

  • Taille de ligne de la réponse à la requête

  • Estimations de la cardinalité des colonnes

• Toute modification récente des schémas de table, des index ou des modèles de charge de travail

• Métriques de limitation issues des profils de requête

• Différences de performance entre les entrepôts froids et les entrepôts chauds

Incluez si possible des exemples rapides et lents de requêtes similaires, afin de faciliter l’identification des possibilités d’optimisation. Cette comparaison aide les équipes d’assistance à identifier rapidement les améliorations potentielles de la configuration ou de la conception.