Vue d’ensemble de la suppression réversible

S’applique à : ✅Azure Data Explorer

La possibilité de supprimer des enregistrements individuels est prise en charge. La suppression d’enregistrements est généralement obtenue à l’aide de l’une des méthodes suivantes :

• Pour supprimer des enregistrements avec une garantie système que les artefacts de stockage contenant ces enregistrements sont également supprimés, utilisez .purge
• Pour supprimer des enregistrements sans une telle garantie, utilisez .delete comme décrit dans cet article : cette commande marque les enregistrements comme supprimés, mais ne supprime pas nécessairement les données des artefacts de stockage. Cette méthode de suppression est plus rapide que la purge.

Pour plus d’informations sur l’utilisation de la commande, consultez Syntaxe

Cas d’utilisation

Cette méthode de suppression ne doit être utilisée que pour la suppression non planifiée d’enregistrements individuels. Par exemple, si vous découvrez qu’un appareil IoT signale des données de télémétrie endommagées pendant un certain temps, vous devez envisager d’utiliser cette méthode pour supprimer les données endommagées.

Si vous devez fréquemment supprimer des enregistrements pour la déduplication ou les mises à jour, nous vous recommandons d’utiliser des vues matérialisées. Consultez choisir entre les vues matérialisées et la suppression réversible pour la déduplication des données.

Processus de suppression

Le processus de suppression réversible est effectué en procédant comme suit :

1. Exécuter une requête de prédicat : la table est analysée pour identifier les étendues de données qui contiennent des enregistrements à supprimer. Les étendues identifiées sont celles avec un ou plusieurs enregistrements retournés par la requête de prédicat.
2. Remplacement des étendues : les étendues identifiées sont remplacées par de nouvelles étendues qui pointent vers les objets blob de données d’origine et ont également une nouvelle colonne masquée de type bool qui indique par enregistrement s’il a été supprimé ou non. Une fois terminée, si aucune nouvelle donnée n’est ingérée, la requête de prédicat ne retourne aucun enregistrement s’il est réexécuté.

Limitations et considérations

• Le processus de suppression est définitif et irréversible. Il n’est pas possible d’annuler ce processus ou de récupérer des données qui ont été supprimées, même si les artefacts de stockage ne sont pas nécessairement supprimés après l’opération.

• La suppression réversible est prise en charge pour les tables natives et les vues matérialisées. Elle n’est pas prise en charge pour les tables externes.

• Avant d’exécuter la suppression réversible, vérifiez le prédicat en exécutant une requête et en vérifiant que les résultats correspondent au résultat attendu. Vous pouvez également exécuter la commande en whatif mode, qui retourne le nombre d’enregistrements censés être supprimés.

• N’exécutez pas plusieurs opérations de suppression réversible parallèle sur la même table, car cela peut entraîner des échecs de certaines ou de toutes les commandes. Toutefois, il est possible d’exécuter plusieurs opérations de suppression réversible parallèle sur différentes tables.

• N’exécutez pas de commandes de suppression réversible et de vidage sur la même table en parallèle. Attendez d’abord qu’une commande se termine, puis exécutez l’autre commande.

• La suppression réversible est exécutée sur votre URI de cluster : https://[YourClusterName].[region].kusto.windows.net. La commande nécessite des autorisations d’administrateur de base de données sur la base de données appropriée.

• La suppression d’enregistrements d’une table qui est une table source d’une vue matérialisée peut avoir un impact sur la vue matérialisée. Si les enregistrements supprimés n’ont pas encore été traités par le cycle de matérialisation, ces enregistrements sont manquants dans l’affichage, car ils ne seront jamais traités. De même, la suppression n’aura pas d’impact sur la vue matérialisée si les enregistrements ont déjà été traités.

• Limitations du prédicat :

  • Il doit contenir au moins un where opérateur.
  • Elle ne peut référencer que la table à partir de laquelle les enregistrements doivent être supprimés.
  • Seuls les opérateurs suivants sont autorisés : extend, , orderproject, take et where. Dans toscalar(), l’opérateur summarize est également autorisé.

Performances de suppression

Les principales considérations qui peuvent avoir un impact sur les performances du processus de suppression sont les suivantes :

• Exécuter une requête de prédicat : les performances de cette étape sont très similaires aux performances du prédicat lui-même. Il peut être légèrement plus rapide ou plus lent en fonction du prédicat, mais la différence devrait être insignifiante.
• Remplacement des étendues : les performances de cette étape dépendent des éléments suivants :
  • Distribution d’enregistrements dans les étendues de données dans le cluster
  • Nombre de nœuds dans le cluster

Contrairement .purgeà , la .delete commande ne reingest pas les données. Il marque simplement les enregistrements retournés par la requête de prédicat comme supprimés et est donc beaucoup plus rapide.

Performances des requêtes après suppression

Les performances des requêtes ne sont pas censées changer de façon notable après la suppression des enregistrements.

La dégradation des performances n’est pas attendue, car le filtre qui est automatiquement ajouté sur toutes les requêtes qui filtrent les enregistrements supprimés est efficace.

Toutefois, les performances des requêtes ne sont pas garanties pour s’améliorer. Même si l’amélioration des performances peut se produire pour certains types de requêtes, cela peut ne pas se produire pour d’autres. Pour améliorer les performances des requêtes, les étendues dans lesquelles la plupart des enregistrements sont supprimés sont régulièrement compactées en les remplaçant par de nouvelles étendues qui contiennent uniquement les enregistrements qui n’ont pas été supprimés.

Impact sur COGS (coût des biens vendus)

Dans la plupart des cas, la suppression d’enregistrements n’entraîne pas de changement de COGS.

• Il n’y aura pas de diminution, car aucun enregistrement n’est réellement supprimé. Les enregistrements sont uniquement marqués comme supprimés à l’aide d’une colonne masquée de type bool, dont la taille est négligeable.
• Dans la plupart des cas, il n’y aura aucune augmentation, car l’opération .delete ne nécessite pas l’approvisionnement de ressources supplémentaires.
• Dans certains cas, les étendues dans lesquelles la majorité des enregistrements sont supprimés sont régulièrement compactées en les remplaçant par de nouvelles étendues qui contiennent uniquement les enregistrements qui n’ont pas été supprimés. Cela entraîne la suppression des anciens artefacts de stockage qui contiennent un grand nombre d’enregistrements supprimés. Les nouvelles étendues sont plus petites et consomment donc moins d’espace dans le compte de stockage et dans le cache chaud. Toutefois, dans la plupart des cas, l’effet de ceci sur COGS est négligeable.