Udostępnij za pośrednictwem


Omówienie usuwania nietrwałego

Dotyczy: ✅Azure Data Explorer

Możliwość usuwania poszczególnych rekordów jest obsługiwana. 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 polecenia .delete 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 użycia

Ta metoda usuwania powinna być używana tylko w przypadku 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żywanie zmaterializowanych widoków. Zobacz wybór między zmaterializowanymi widokami a usuwaniem nietrwałym na potrzeby deduplikacji danych.

Proces usuwania

Proces usuwania nietrwałego jest wykonywany, wykonując następujące czynności:

  1. Uruchamianie zapytania predykatu: tabela jest skanowana w celu zidentyfikowania zakresów danych, które zawierają 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 mają nową ukrytą kolumnę typu bool , która wskazuje, czy rekord został usunięty, czy nie. Po zakończeniu, jeśli nowe dane nie zostaną pozyskane, zapytanie predykatu nie zwróci żadnych rekordów w przypadku ponownego uruchomienia.

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ą być usuwane po operacji.

  • Usuwanie nietrwałe jest obsługiwane w przypadku tabel natywnych i zmaterializowanych widoków. Nie jest obsługiwany 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żna 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, ponieważ może to spowodować błędy niektórych lub wszystkich poleceń. Można jednak uruchamiać wiele równoległych operacji usuwania nietrwałego w różnych tabelach.

  • Nie uruchamiaj poleceń usuwania nietrwałego i przeczyszczania w tej samej tabeli równolegle. Najpierw poczekaj 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 do odpowiedniej bazy 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 dotyczące 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, , projectordertake i .where W programie toscalar()summarize operator jest również dozwolony.

Wydajność usuwania

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

  • Uruchamianie zapytania 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 oczekuje się, że różnica będzie nieznaczna.
  • Zastąpienie 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 to tylko rekordy zwracane przez zapytanie predykatu jako usunięte i dlatego jest znacznie szybsze.

Wydajność zapytań po usunięciu

Wydajność zapytań nie powinna być zauważalnie zmieniana 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ć w przypadku 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 są rzeczywiście usuwane. Rekordy są oznaczone jako usunięte tylko przy użyciu ukrytej kolumny typu bool, której rozmiar jest niewielki.
  • W większości przypadków nie zostanie zwiększony, ponieważ .delete operacja nie wymaga aprowizacji dodatkowych zasobów.
  • W niektórych przypadkach zakresy, w których większość rekordów są okresowo kompaktowane, zastępując je 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 zarówno na koncie magazynu, jak i w gorącej pamięci podręcznej. Jednak w większości przypadków wpływ tego na COGS jest niewielki.