Vue d’ensemble de la suppression réversible

Article
07/30/2023

En tant que plateforme de données, Azure Data Explorer prend en charge la possibilité de supprimer des enregistrements individuels. La suppression d’enregistrements est généralement effectuée à 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 cette 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 :

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.
Remplacement des extensions : 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é, si aucune nouvelle donnée n’est ingérée, la requête de prédicat ne retourne aucun enregistrement si elle est réexécutée.

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. Il n’est pas pris 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 qui sont censés être supprimés.
N’exécutez pas plusieurs opérations de suppression réversible parallèles 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èles sur différentes tables.
N’exécutez pas de commandes de suppression réversible et de purge sur la même table en parallèle. Attendez d’abord qu’une commande se termine, puis exécutez uniquement l’autre commande.
La suppression réversible est exécutée sur l’URI de votre 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 seront manquants dans la vue, 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.
- Il peut uniquement référencer la table à partir de laquelle les enregistrements doivent être supprimés.
- Seuls les opérateurs suivants sont autorisés : extend, order, projectet wheretake . Dans toscalar(), l’opérateur summarize est également autorisé.

Performances de suppression

Les considérations main 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 selon le prédicat, mais la différence devrait être insignifiante.
Remplacement des extensions : les performances de cette étape dépendent des éléments suivants :
- Distribution d’enregistrements entre les étendues de données dans le cluster
- Nombre de nœuds dans le cluster

Contrairement à .purge, la .delete commande ne reingeste 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 la suppression

Les performances des requêtes ne devraient pas changer sensiblement après la suppression des enregistrements.

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

Toutefois, l’amélioration des performances des requêtes n’est pas garantie. Bien que l’amélioration des performances puisse se produire pour certains types de requêtes, elle peut ne pas se produire pour d’autres. Afin d’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 le COGS (coût des marchandises vendues)

Dans la plupart des cas, la suppression d’enregistrements n’entraîne pas de modification 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 pas d’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.

Partage via