Udostępnij za pośrednictwem


Omówienie usuwania nietrwałego

Jako platforma danych platforma Azure Data Explorer obsługuje możliwość usuwania poszczególnych rekordów. Usuwanie rekordów jest często osiągane przy użyciu jednej z następujących metod:

  • Aby usunąć rekordy z gwarancją systemu, że artefakty magazynu zawierające te rekordy również zostaną usunięte, użyj polecenia .purge
  • Aby usunąć rekordy bez takiej gwarancji, użyj .delete polecenia zgodnie z opisem w tym artykule — to polecenie oznacza rekordy jako usunięte, ale niekoniecznie usuwa dane z artefaktów magazynu. Ta metoda usuwania jest szybsza niż przeczyszczanie.

Aby uzyskać informacje na temat używania polecenia, zobacz Składnia

Przypadki zastosowań

Ta metoda usuwania powinna być używana tylko do nieplanowanego usuwania poszczególnych rekordów. Jeśli na przykład okaże się, że urządzenie IoT zgłasza uszkodzone dane telemetryczne przez jakiś czas, należy rozważyć użycie tej metody w celu usunięcia uszkodzonych danych.

Jeśli musisz często usuwać rekordy na potrzeby deduplikacji lub aktualizacji, zalecamy użycie zmaterializowanych widoków. Zobacz wybór między zmaterializowanymi widokami a usuwaniem nietrwałym w celu deduplikacji danych.

Proces usuwania

Proces usuwania nietrwałego jest wykonywany przy użyciu następujących kroków:

  1. Uruchom zapytanie predykatu: tabela jest skanowana w celu zidentyfikowania zakresów danych zawierających rekordy do usunięcia. Zidentyfikowane zakresy to te z co najmniej jednym rekordem zwracanym przez zapytanie predykatu.
  2. Zastąpienie zakresów: zidentyfikowane zakresy są zastępowane nowymi zakresami wskazującymi oryginalne obiekty blob danych, a także nową ukrytą kolumnę typu bool , która wskazuje na rekord, czy został usunięty, czy nie. Po zakończeniu, jeśli żadne nowe dane nie zostaną pozyskane, zapytanie predykatu nie zwróci żadnych rekordów po ponownym uruchomieniu.

Ograniczenia i istotne zagadnienia

  • Proces usuwania jest ostateczny i nieodwracalny. Nie można cofnąć tego procesu ani odzyskać usuniętych danych, mimo że artefakty magazynu nie muszą zostać usunięte po wykonaniu tej operacji.

  • Usuwanie nietrwałe jest obsługiwane w przypadku tabel natywnych i zmaterializowanych widoków. Nie jest obsługiwana w przypadku tabel zewnętrznych.

  • Przed uruchomieniem usuwania nietrwałego sprawdź predykat, uruchamiając zapytanie i sprawdzając, czy wyniki są zgodne z oczekiwanym wynikiem. Możesz również uruchomić polecenie w whatif trybie, który zwraca liczbę rekordów, które mają zostać usunięte.

  • Nie uruchamiaj wielu równoległych operacji usuwania nietrwałego w tej samej tabeli, co może spowodować awarie niektórych lub wszystkich poleceń. Można jednak uruchamiać wiele równoległych operacji usuwania nietrwałego w różnych tabelach.

  • Nie uruchamiaj nietrwałych poleceń usuwania i przeczyszczania w tej samej tabeli równolegle. Najpierw zaczekaj na ukończenie jednego polecenia, a następnie uruchom drugie polecenie.

  • Usuwanie nietrwałe jest wykonywane względem identyfikatora URI klastra: https://[YourClusterName].[region].kusto.windows.net. Polecenie wymaga uprawnień administratora bazy danych w odpowiedniej bazie danych.

  • Usunięcie rekordów z tabeli, która jest tabelą źródłową zmaterializowanego widoku, może mieć wpływ na zmaterializowany widok. Jeśli usunięte rekordy nie zostały jeszcze przetworzone przez cykl materializacji, te rekordy nie będą w widoku, ponieważ nigdy nie zostaną przetworzone. Podobnie usunięcie nie będzie miało wpływu na zmaterializowany widok, jeśli rekordy zostały już przetworzone.

  • Ograniczenia predykatu:

    • Musi zawierać co najmniej jeden where operator.
    • Może odwoływać się tylko do tabeli, z której mają zostać usunięte rekordy.
    • Dozwolone są tylko następujące operatory: extend, order, projecti takewhere. summarize W programie toscalar()operator jest również dozwolony.

Wydajność usuwania

Główne zagadnienia, które mogą mieć wpływ na wydajność procesu usuwania , to:

  • Uruchom zapytanie predykatu: wydajność tego kroku jest bardzo podobna do wydajności samego predykatu. Może to być nieco szybsze lub wolniejsze w zależności od predykatu, ale różnica powinna być nieznaczna.
  • Zamiana zakresów: wydajność tego kroku zależy od następujących elementów:
    • Dystrybucja rekordów w zakresach danych w klastrze
    • Liczba węzłów w klastrze

W przeciwieństwie do .purgepolecenia .delete polecenie nie pozyskuje danych. Oznacza tylko rekordy, które są zwracane przez zapytanie predykatu jako usunięte i dlatego jest znacznie szybsze.

Wydajność zapytań po usunięciu

Wydajność zapytań nie ma zauważalnej zmiany po usunięciu rekordów.

Obniżenie wydajności nie jest oczekiwane, ponieważ filtr, który jest automatycznie dodawany do wszystkich zapytań odfiltrowanych rekordów, które zostały usunięte, jest wydajny.

Jednak wydajność zapytań nie jest również gwarantowana, aby poprawić. Chociaż w przypadku niektórych typów zapytań może wystąpić poprawa wydajności, może się to nie zdarzyć dla niektórych innych. Aby zwiększyć wydajność zapytań, zakresy, w których większość rekordów jest usuwana, są okresowo kompaktowane przez zastąpienie ich nowymi zakresami, które zawierają tylko rekordy, które nie zostały usunięte.

Wpływ na COGS (koszt sprzedanych towarów)

W większości przypadków usunięcie rekordów nie spowoduje zmiany COGS.

  • Nie będzie żadnych spadków, ponieważ żadne rekordy nie zostaną rzeczywiście usunięte. Rekordy są oznaczone tylko jako usunięte przy użyciu ukrytej kolumny typu bool, którego rozmiar jest nieznaczny.
  • W większości przypadków nie będzie żadnych podwyżek, ponieważ .delete operacja nie wymaga aprowizacji dodatkowych zasobów.
  • W niektórych przypadkach zakresy, w których większość rekordów jest usuwana, są okresowo kompaktowane przez zastąpienie ich nowymi zakresami, które zawierają tylko rekordy, które nie zostały usunięte. Powoduje to usunięcie starych artefaktów magazynu zawierających dużą liczbę usuniętych rekordów. Nowe zakresy są mniejsze i w związku z tym zużywają mniej miejsca na koncie magazynu i w gorącej pamięci podręcznej. Jednak w większości przypadków wpływ tego na COGS jest nieznaczny.