12-14 novembre 2024 — Notes de version 8.43¶

Recherche en texte intégral — Disponibilité générale¶

La recherche en texte intégral est désormais disponible de manière générale. Pour utiliser la recherche en texte intégral, appelez les nouvelles fonctions SEARCH et SEARCH_IP pour trouver des données de type caractère (texte) et des adresses IP dans des colonnes spécifiées d’une table, y compris des éléments dans les colonnes VARIANT, OBJECT et ARRAY. Dans la plupart des cas, vous appelez la fonction en la spécifiant dans la liste SELECT ou la clause WHERE d’une instruction SELECT.

La fonction SEARCH prend en charge la recherche de texte basée sur des jetons dans plusieurs colonnes (ou toutes les colonnes) d’une table, ce qui constitue une bonne solution pour les cas d’utilisation suivants :

• Recherche de texte dans des données avec une structure inhérente, où les jetons correspondent naturellement à des mots, des champs ou des composants de message.

  Les recherches de jetons peuvent correspondre exactement au texte spécifié dans une grande quantité de données, ce qui entraîne moins de faux positifs et des requêtes plus simples que les recherches de sous-chaînes. Par exemple, une recherche de jeton pour « accès non autorisé » dans les journaux système trouve des instances non sensibles à la casse de « non autorisé » et « accès », mais ne trouve pas d’instances de « autorisé » ou « accessible ».

  En outre, dans ces cas, SEARCH est généralement plus rapide que les requêtes comparables qui utilisent ILIKE.

• Rechercher de texte sans connaître l’emplacement exact des données pertinentes. Étant donné que la recherche en texte intégral prend en charge un caractère générique de colonne, vous pouvez rechercher du texte pertinent dans un ensemble de colonnes ou des tables entières sans écrire de requêtes SQL complexes. Par exemple, vous pouvez utiliser la recherche en texte intégral pour rechercher une liste de noms d’utilisateur dans une table.

La fonction SEARCH_IP recherche les adresses IPv4 valides dans les colonnes de chaînes de caractères spécifiées, y compris les éléments des colonnes VARIANT, OBJECT et ARRAY. La recherche peut trouver des correspondances pour une seule adresse IP ou une plage CIDR d’adresses IP dans une grande quantité de données.

Pour améliorer les performances des requêtes de recherche en texte intégral, vous pouvez éventuellement activer l’optimisation de la recherche FULL_TEXT sur une colonne ou un ensemble de colonnes spécifiques dans une table. Pour ce faire, exécutez une instruction ALTER TABLE … ADD SEARCH OPTIMIZATION ON FULL_TEXT. Le chemin d’accès qui en résulte est généralement plus rapide et moins coûteux à établir et nécessite moins de stockage sur le disque que ON SUBSTRING.

Pour plus d’informations sur la recherche en texte intégral, voir Utilisation de la recherche en texte intégral. Pour plus d’informations sur l’optimisation de la recherche pour les requêtes de recherche en texte intégral, voir Activation et désactivation de l’optimisation de la recherche.

Protection contre les fuites de mots de passe¶

Avec cette version, nous avons le plaisir d’annoncer la protection contre les fuites de mots de passe, un service en arrière-plan dans Snowflake qui surveille et désactive les mots de passe qui ont fait l’objet d’une fuite pour aider à prévenir l’accès non autorisé aux comptes Snowflake. Le service de protection contre les fuites de mots de passe fournit un système de notification aux administrateurs afin qu’ils soient informés des fuites de mots de passe lorsqu’elles sont détectées dans des bases de données externes.

Pour plus d’informations, voir Protection contre les fuites de mots de passe.

Tâches : prise en charge de Python et de JVM pour les tâches sans serveur — Disponibilité générale¶

Avec cette version, nous avons le plaisir d’annoncer la disponibilité générale de la prise en charge de Python et de JVM pour les tâches sans serveur. Les tâches sans serveur peuvent désormais appeler les types d’objets et fonctions suivants : UDFs (fonctions définies par l’utilisateur) et procédures stockées écrites en Python, Java et Scala. Pour plus d’informations, voir Prise en charge de Python et Java pour les tâches sans serveur.

EXECUTE IMMEDIATE FROM : prise en charge de l’utilisation du contenu des fichiers en zone de préparation dans les modèles¶

Avec cette version, dans un modèle Jinja2, vous pouvez inclure, importer, hériter du et lire le contenu d’autres fichiers dans une zone de préparation.

Vous pouvez utiliser les fonctions include, import et inheritance de Jinja2 ou appeler l”API SnowflakeFile afin d’utiliser le contenu des fichiers dans une zone de préparation. Cela vous permet de rendre vos modèles plus modulaires. Par exemple, vous pouvez définir des macros dans un fichier commun et utiliser ces macros dans différents modèles.

Pour plus d’informations, voir Utilisation du contenu de fichiers en zone de préparation dans un modèle.

Journalisation et traçage automatique des procédures stockées Snowflake Scripting¶

Avec cette version, vous pouvez automatiquement journaliser et émettre des informations de traçage sur l’exécution d’une procédure stockée Snowflake Scripting. Les informations de journalisation supplémentaires comprennent BEGIN/END d’un bloc Snowflake Scripting et d’une requête de tâche enfant. Les autres types d’événements de traçage comprennent la capture des exceptions, les informations sur l’exécution des tâches enfants, les statistiques sur les tâches enfants et les statistiques sur les procédures stockées, y compris la durée d’exécution et les valeurs d’entrée. Grâce à cette fonction, vous pouvez générer ces informations supplémentaires sans modifier le corps de la procédure stockée.

Pour utiliser la fonction, définissez le nouveau paramètre AUTO_EVENT_LOGGING sur LOGGING, TRACING ou ALL via la commande ALTER PROCEDURE.

Pour plus d’informations, voir Ajouter automatiquement des messages de journal sur les blocs et les tâches enfants et Émettre automatiquement des événements de trace pour les tâches enfants et les exceptions.

ACCOUNT_USAGE : nouvelle vue SERVERLESS_ALERT_HISTORY¶

Avec cette version, nous avons le plaisir d’annoncer le lancement de la vue SERVERLESS_ALERT_HISTORY dans le schéma ACCOUNT_USAGE de la base de données SNOWFLAKE partagée. Vous pouvez interroger cette vue pour obtenir des informations sur les crédits utilisés pour les alertes sans serveur.

Pour plus d’informations, voir Vue SERVERLESS_ALERT_HISTORY.

Authentification auprès d’AWS IAM à partir des procédures et des fonctions — Disponibilité générale¶

Avec cette version, nous avons le plaisir d’annoncer la disponibilité générale de la prise en charge de l’authentification auprès des services AWS à partir d’une procédure ou de fonctions utilisant Snowpark External Access via Gestion des identités et des accès (Identity and Access Management ou IAM).

Pour plus d’informations, voir Accéder à Amazon S3 avec AWS IAM.

LISTING_REFRESH_HISTORY — Disponibilité générale¶

Avec cette version, nous avons le plaisir d’annoncer la disponibilité générale de la nouvelle fonction LISTING_REFRESH_HISTORY. Vous pouvez utiliser cette fonction pour afficher les 14 derniers jours de l’historique d’actualisation d’une annonce d’exécution automatique inter-Cloud. Les informations renvoyées contiennent des détails de réplication des événements d’actualisation au cours desquels l’annonce est synchronisée avec une région cible spécifiée.

Pour plus d’informations, voir LISTING_REFRESH_HISTORY.

Tables dynamiques : prise en charge de la réplication sur différents groupes de basculement¶

Avec cette version, nous avons le plaisir d’annoncer la prise en charge de la réplication de tables dynamiques et de tables de base qui se trouvent dans des groupes de basculement différents.

Pour plus d’informations, consultez Réplication et tables dynamiques.

Tables Apache Iceberg™ : prise en charge du stockage Microsoft Fabric OneLake — Avant-première¶

Avec cette version, nous avons le plaisir d’annoncer la prise en charge de Microsoft Fabric OneLake comme destination de stockage pour les tables Iceberg. Vous pouvez désormais créer un volume externe qui connecte Snowflake au stockage Fabric OneLake, puis créer une table gérée par Snowflake qui écrit à cet emplacement. Vous pouvez lancer des requêtes sur la table via Snowflake et Fabric.

Pour plus d’informations, voir CREATE EXTERNAL VOLUME.