Udostępnij za pośrednictwem

Polecenie .update table

  • Artykuł

Polecenie .update table wykonuje aktualizacje danych w określonej tabeli przez niepodzielne usuwanie i dołączanie rekordów.

Ostrzeżenie

To polecenie jest nieodwracalne.

Uwaga

Po uruchomieniu .update table polecenia w tabeli, która jest źródłem zasad aktualizacji, polecenie wyzwala te zasady aktualizacji, .update table dla których modyfikowana tabela jest źródłem zasad aktualizacji.

W jednym poleceniu można usunąć maksymalnie 5 milionów rekordów.

Uprawnienia

Aby uruchomić to polecenie, musisz mieć co najmniej uprawnienia administratora tabeli.

Składnia

Uwaga

Uproszczona składnia, która była dostępna w wersji zapoznawczej, jest przestarzała.

Dowiedz się więcej na temat konwencji składni.

.update[async] table TableName delete DeleteIdentifier AppendIdentifier append [with ( propertyName = propertyValue ] )<|
letDeleteIdentifier= DeletePredicate;
letAppendIdentifier= AppendPredicate;

Parametry

Nazwisko Type Wymagania opis
async string Jeśli zostanie określony, wskazuje, że polecenie jest uruchamiane w trybie asynchronicznym.
TableName string ✔️ Nazwa tabeli do zaktualizowania.
DeleteIdentifier string ✔️ Nazwa identyfikatora używana do określania predykatu usuwania zastosowanego do zaktualizowanej tabeli.
DeletePredicate string ✔️ Tekst zapytania, którego wyniki są używane jako dane do usunięcia. Predykat ma te same ograniczenia co predykat usuwania nietrwałego.
AppendIdentifier string ✔️ Nazwa identyfikatora używana do określania predykatu dołączania zastosowanego do zaktualizowanej tabeli.
AppendPredicate string ✔️ Tekst zapytania, którego wyniki są używane jako dane do dołączania.

Ważne

  • Predykaty usuwania i dołączania nie mogą używać jednostek zdalnych, między bazami danych i między klastrami. Predykaty nie mogą odwoływać się do tabeli zewnętrznej ani używać externaldata operatora.
  • Oczekuje się, że zapytania dołączania i usuwania generują wyniki deterministyczne. Zapytania nieokreślone mogą prowadzić do nieoczekiwanych wyników. Zapytanie jest deterministyczne, jeśli i tylko wtedy, gdy zwróci te same dane, jeśli zostaną wykonane wiele razy.
    • Na przykład użycie operatorów, operatorówtake, rand funkcji i innych takich operatorów nie jest zalecane, ponieważ te operatory nie są deterministyczne.sample
  • Zapytania mogą być wykonywane więcej niż raz w ramach update wykonywania. Jeśli wyniki zapytania pośredniego są niespójne, polecenie aktualizacji może wygenerować nieoczekiwane wyniki.

Obsługiwane właściwości

Nazwisko Pisz Opis
whatif bool Jeśli trueparametr zwraca liczbę rekordów, które zostaną dołączone/usunięte w każdym fragmentie, bez dołączania/usuwania jakichkolwiek rekordów. Wartość domyślna to false.
Rozproszonych bool Jeśli truepolecenie jest pozyskiwane ze wszystkich węzłów wykonujących zapytanie równolegle. Wartość domyślna to false. Zobacz porady dotyczące wydajności.

Ważne

Zalecamy najpierw uruchomienie trybu w whatif trybie przed wykonaniem aktualizacji w celu zweryfikowania predykatów przed usunięciem lub dołączeniem danych.

Zwraca

Wynikiem polecenia jest tabela, w której każdy rekord reprezentuje zakres , który został utworzony z nowymi danymi lub miał usunięte rekordy.

Nazwisko Pisz Opis
Tabela string Tabela, w której zakres został utworzony lub usunięty.
Akcja string Utwórz lub usuń w zależności od akcji wykonanej w zakresie.
ExtentId guid Unikatowy identyfikator zakresu, który został utworzony lub usunięty przez polecenie .
RowCount long Liczba wierszy utworzonych lub usuniętych w określonym zakresie za pomocą polecenia .

Wybieranie między widokami .update table i zmaterializowanych

Istnieją scenariusze, w których można użyć .update table polecenia lub zmaterializowanego widoku , aby osiągnąć ten sam cel w tabeli. Na przykład zmaterializowany widok może służyć do przechowywania najnowszej wersji każdego rekordu lub aktualizacji można użyć do aktualizowania rekordów, gdy jest dostępna nowa wersja.

Skorzystaj z poniższych wskazówek, aby zdecydować, która metoda ma być używana:

  • Jeśli wzorzec aktualizacji nie jest obsługiwany przez zmaterializowane widoki, użyj polecenia update.
  • Jeśli tabela źródłowa ma duży wolumin pozyskiwania, ale tylko kilka aktualizacji, użycie polecenia aktualizacji może być bardziej wydajne i zużywać mniej pamięci podręcznej lub magazynu niż zmaterializowane widoki. Dzieje się tak, ponieważ zmaterializowane widoki muszą ponownie przetwarzać wszystkie pozyskane dane, co jest mniej wydajne niż identyfikowanie poszczególnych rekordów do aktualizacji na podstawie predykatów dołączania lub usuwania.
  • Zmaterializowane widoki to w pełni zarządzane rozwiązanie. Zmaterializowany widok jest definiowany raz , a materializacja odbywa się w tle przez system. Polecenie aktualizacji wymaga zorganizowanych procesów (na przykład Azure Data Factory, Logic Apps, Power Automate i innych), który jawnie wykonuje polecenie aktualizacji za każdym razem, gdy są dostępne aktualizacje. Jeśli zmaterializowane widoki działają wystarczająco dobrze w przypadku użycia, użycie zmaterializowanych widoków wymaga mniejszego zarządzania i konserwacji.

Wskazówki dotyczące wydajności

  • Pozyskiwanie danych to operacja intensywnie korzystająca z zasobów, która może mieć wpływ na współbieżne działania w klastrze, w tym uruchamianie zapytań. Zalecamy unikanie następujących akcji intensywnie korzystających z zasobów: uruchamianie wielu .update poleceń jednocześnie i intensywne korzystanie z właściwości rozproszonej.
  • Ogranicz dołączanie danych do mniej niż 1 GB na operację. W razie potrzeby użyj wielu poleceń aktualizacji.
  • Ustaw flagę distributed na true wartość tylko wtedy, gdy ilość danych generowanych przez zapytanie jest duża, przekracza 1 GB i nie wymaga serializacji: wiele węzłów może następnie generować dane wyjściowe równolegle. Nie używaj tej flagi, gdy wyniki zapytania są małe, ponieważ może niepotrzebnie generować wiele małych fragmentów danych.

Przykłady

W przykładach użyjemy poniższej tabeli:

.set-or-replace Employees <|
  range i from 1 to 100 step 1
  | project Id=i
  | extend Code = tostring(dynamic(["Customer", "Employee"])[Id %2])
  | extend Color = tostring(dynamic(["Red", "Blue", "Gray"])[Id %3])

To polecenie tworzy tabelę z 100 rekordami rozpoczynającymi się od:

ID Kod Color
1 Pracownik Niebieskie
2 Klient Szary
3 Pracownik Czerwony
100 Klient Niebieskie
5 Pracownik Szary
6 Klient Czerwony
6 Pracownik Niebieskie

Aktualizowanie pojedynczej kolumny w jednym wierszu

Poniższy przykład aktualizuje pojedynczą kolumnę w jednym wierszu:

.update table Employees delete D append A with(whatif=true) <|
    let D = Employees
      | where Id==3;
    let A = Employees
      | where Id==3
      | extend Color="Orange";

Zwróć uwagę, że whatif ustawiono wartość true. Po wykonaniu tego zapytania tabela pozostaje niezmieniona, ale polecenie zwraca, że istnieje zakres z jednym wierszem usuniętym i nowym zakresem z jednym wierszem.

Następujące polecenie faktycznie wykonuje aktualizację:

.update table Employees delete D append A <|
    let D = Employees
      | where Id==3;
    let A = Employees
      | where Id==3
      | extend Color="Orange";

Aktualizowanie pojedynczej kolumny w wielu wierszach

Poniższy przykład aktualizuje jedną kolumnę Color do wartości Green w tych wierszach, które mają wartość niebieską.

.update table Employees delete D append A <|
    let D = Employees
        | where Code=="Employee"
        | where Color=="Blue";
    let A = D
      | extend Color="Green";

W tym miejscu ponownie użyto identyfikatora usuwania w definicji w predykacie dołączania.

Aktualizowanie wielu kolumn w wielu wierszach

Poniższy przykład aktualizuje wiele kolumn we wszystkich wierszach z kolorem szarym.

.update table Employees delete D append A <|
    let D = Employees
      | where Color=="Gray";
    let A = D
      | extend Code=strcat("ex-", Code)
      | extend Color="";

Aktualizowanie wierszy przy użyciu innej tabeli

W tym przykładzie pierwszym krokiem jest utworzenie następującej tabeli mapowania:

.set-or-replace ColorMapping <|
  datatable(OldColor:string, NewColor:string)[
    "Red", "Pink",
    "Blue", "Purple",
    "Gray", "LightGray",
    "Orange", "Yellow",
    "Green", "AppleGreen"
  ]

Ta tabela mapowania jest następnie używana do aktualizowania niektórych kolorów w oryginalnej tabeli:

.update table Employees delete D append A <|
  let D = Employees
    | where Code=="Customer";
  let A = D
    | lookup ColorMapping on $left.Color==$right.OldColor
    | project Id, Code, Color=NewColor

Aktualizowanie wierszy przy użyciu tabeli przejściowej

Popularnym wzorcem jest najpierw wylądowanie danych w tabeli przejściowej przed zaktualizowaniem tabeli głównej.

Pierwsze polecenie tworzy tabelę przejściową:

.set-or-replace MyStagingTable <|
    range i from 70 to 130 step 5
    | project Id=i
    | extend Code = tostring(dynamic(["Customer", "Employee"])[Id %2])
    | extend Color = tostring(dynamic(["Red", "Blue", "Gray"])[Id %3])

Następne polecenie aktualizuje tabelę główną przy użyciu danych w tabeli przejściowej:

.update table Employees delete D append A <|
    let A = MyStagingTable;
    let D = Employees
        | join kind=leftsemi MyStagingTable on Id
        | where true;

Niektóre rekordy w tabeli przejściowej nie istniały w tabeli głównej (czyli w Id>100tabeli głównej ), ale nadal zostały wstawione do tabeli głównej (zachowanie upsert).

Klucz złożony

Pierwsze polecenie tworzy tabelę z kluczami złożonymi:

.set-or-replace VersionedArticle <|
  datatable(ArticleId:string, Version:int, Detail:string)[
    "A", 1, "Early version",
    "B", 1, "News about mobiles",
    "C", 1, "Opinion article",
    "B", 2, "Revision about brand X",
    "B", 3, "Revision about brand Y",
    "C", 2, "Fact check"
  ]

Następne polecenie aktualizuje określony rekord przy użyciu rozszerzonej składni:

.update table VersionedArticle delete D append A <|
  let D = VersionedArticle
    | where ArticleId=="B"
    | where Version==3;
  let A = VersionedArticle
    | where ArticleId=="B"
    | where Version==3
    | extend Detail = "Revision about brand Z";

Powiązana zawartość