Souběžnost na úrovni řádků

Souběžnost na úrovni řádků snižuje konflikty mezi souběžnými operacemi zápisu tím, že detekuje změny na úrovni řádku a automaticky řeší konflikty, ke kterým dochází při souběžné aktualizaci zápisu nebo odstranění různých řádků ve stejném datovém souboru.

Požadavky na souběžnost na úrovni řádků

Souběžnost na úrovni řádků se automaticky povolí, pokud jsou splněny všechny následující požadavky:

  • Použití Databricks Runtime ve verzi 14.3 LTS a vyšší
  • Zdrojová tabulka nepoužívá oddíly.
  • Zdrojová tabulka obsahuje povolené vektory odstranění. Podívejte se na vektory odstranění v Databricks.

Dělené tabulky neumožňují souběžnost na úrovni řádků. Pokud jsou však povoleny vektory odstranění, partitionované tabulky se i nadále mohou vyhnout konfliktům mezi OPTIMIZE a operacemi zápisu. Viz Omezení souběžnosti na úrovni řádků.

Pro verze Databricks Runtime starší než 14.3 LTS viz Původní chování souběžnosti na úrovni řádků.

Matice konfliktů se souběžností na úrovni řádků

Pro zdrojové tabulky s souběžností na úrovni řádků následující tabulka ukazuje, jak se každá dvojice souběžných zápisových operací chová v každé úrovni izolace.

Současné změny metadat jsou výjimkou u každého výsledku v tabulce. Změna metadat, například ALTER TABLE příkaz nebo zápis, který aktualizuje schéma tabulky, může způsobit selhání všech souběžných zápisových operací, včetně INSERT. Viz konflikty změn metadat.

Operační pár WriteSerializable (výchozí) Serializovatelný
INSERT (1) + INSERT Nemůže být v rozporu Nemůže být v rozporu
INSERT + UPDATE, DELETE, MERGE INTO Nemůže být v rozporu Může dojít ke konfliktu při úpravě stejného řádku. Operace UPDATE, DELETE, nebo MERGE selže, nikoli .INSERT
INSERT + OPTIMIZE Nemůže být v rozporu Nemůže být v rozporu
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Může kolidovat při úpravě stejného řádku Může kolidovat při úpravě stejného řádku
UPDATE, DELETE, MERGE INTO + OPTIMIZE Může dojít ke konfliktu použitím ZORDER BY. Nemůže to být v rozporu jinak. Může dojít ke konfliktu použitím ZORDER BY. Nemůže to být v rozporu jinak.
OPTIMIZE + OPTIMIZE Může dojít ke konfliktu použitím ZORDER BY. Nemůže to být v rozporu jinak. Může dojít ke konfliktu použitím ZORDER BY. Nemůže to být v rozporu jinak.

(1) Všechny INSERT operace v této tabulce popisují operace připojení, které neobsahují poddotazy, které čtou data ze stejné tabulky. INSERT operace obsahující poddotazy, které čtou ze stejné tabulky, podporují stejnou souběžnost jako MERGE.

Poznámka:

  • Když může pár kolidovat, selže pouze operace, která načte postižená data. Operace INSERT , která přidává data bez čtení tabulky, není operací, která selže, takže logika opakovaného pokusu patří na souběžnou UPDATE, DELETE, nebo MERGE.
  • Tabulky se sloupci identit nepodporují souběžné transakce. Viz sloupce Identita.
  • REORG operace mají sémantiku izolace stejnou jako OPTIMIZE při přepisování datových souborů. Když použijete REORG ke spuštění upgradu, dojde ke změně protokolů tabulek, což je v rozporu se všemi probíhajícími operacemi.

Konflikty zápisu bez souběžnosti na úrovni řádků

Pro zdrojové tabulky bez souběžnosti na úrovni řádků následující tabulka ukazuje, jak se každá dvojice souběžných zápisových operací chová v každé izolační úrovni.

Současné změny metadat jsou výjimkou u každého výsledku v tabulce. Změna metadat, například ALTER TABLE příkaz nebo zápis, který aktualizuje schéma tabulky, může způsobit selhání všech souběžných zápisových operací, včetně INSERT. Viz konflikty změn metadat.

Operační pár WriteSerializable (výchozí) Serializovatelný
INSERT (1) + INSERT Nemůže být v rozporu Nemůže být v rozporu
INSERT + UPDATE, DELETE, MERGE INTO Nemůže být v rozporu Může být v konfliktu. Operace UPDATE, DELETE, nebo MERGE selže, nikoli .INSERT Viz Zabránění konfliktům pomocí dělení.
INSERT + OPTIMIZE Nemůže být v rozporu Nemůže být v rozporu
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Může být v konfliktu. Viz Zabránění konfliktům pomocí dělení. Může být v konfliktu. Viz Zabránění konfliktům pomocí dělení.
UPDATE, DELETE, MERGE INTO + OPTIMIZE Nelze v tabulkách kolidovat s povolenými vektory odstranění, pokud ZORDER BY se nepoužívá. Může se dostat do konfliktu jinak. Nelze v tabulkách kolidovat s povolenými vektory odstranění, pokud ZORDER BY se nepoužívá. Může se dostat do konfliktu jinak.
OPTIMIZE + OPTIMIZE Nelze v tabulkách kolidovat s povolenými vektory odstranění, pokud ZORDER BY se nepoužívá. Může se dostat do konfliktu jinak. Nelze v tabulkách kolidovat s povolenými vektory odstranění, pokud ZORDER BY se nepoužívá. Může se dostat do konfliktu jinak.

(1) Všechny INSERT operace v této tabulce popisují operace připojení, které neobsahují poddotazy, které čtou data ze stejné tabulky. INSERT operace obsahující poddotazy, které čtou ze stejné tabulky, podporují stejnou souběžnost jako MERGE.

Poznámka:

  • Když může pár kolidovat, selže pouze operace, která načte postižená data. Operace INSERT , která přidává data bez čtení tabulky, není operací, která selže, takže logika opakovaného pokusu patří na souběžnou UPDATE, DELETE, nebo MERGE.
  • Tabulky se sloupci identit nepodporují souběžné transakce. Viz sloupce Identita.
  • REORG operace mají sémantiku izolace stejnou jako OPTIMIZE při přepisování datových souborů. Když použijete REORG k použití upgradu, protokoly tabulek se změní a dostanou se do konfliktu se všemi probíhajícími operacemi.

Omezení souběžnosti na úrovni řádků

Omezení platí pro souběžnost na úrovni řádků. Řešení konfliktů u následujících operací se řídí obvyklou souběžností pro konflikty zápisu. Viz Konflikty zápisu bez souběžnosti na úrovni řádků.

Omezení Description
Komplexní podmíněné klauzule Podmínky pro komplexní datové typy (struktury, pole, mapy), nedeterministické výrazy, poddotazy a korelované poddotazy
MERGE požadavek na predikát V Databricks Runtime 14.2 MERGE musí příkazy použít explicitní predikát v cílové tabulce k filtrování řádků odpovídajících zdrojové tabulce.
Výkonový kompromis Detekce konfliktů na úrovni řádků může zvýšit celkovou dobu provádění. Při mnoha souběžných transakcích zapisovač upřednostňuje latenci oproti řešení konfliktů.

Platí také všechna omezení pro vektory odstranění. Viz Omezení.

Vyhněte se konfliktům pomocí dělení

Ve všech případech označených jako "může kolidovat" v maticích konfliktů dojde ke konfliktu pouze v případě, že dvě operace ovlivňují stejnou sadu souborů. Pokud chcete vytvořit dvě sady souborů oddělené, rozdělte tabulku podle stejných sloupců, které se používají v podmínkách operací.

Příklad:

Pokud tabulka není rozdělena podle data, příkazy UPDATE table WHERE date > '2010-01-01' ... a DELETE table WHERE date < '2010-01-01' konfliktují, protože oba se mohou pokusit upravit stejné soubory. Rozdělením tabulky podle date se vyhnete konfliktu.

Poznámka:

Dělení tabulky podle sloupce s vysokou kardinalitou může vést k problémům s výkonem kvůli velkému počtu podadresářů.

Vyhněte se konfliktům s explicitně zadanými filtry particí

Tato výjimka se často vyvolá během souběžných DELETEUPDATEoperací nebo MERGE operací, které mohou číst stejný oddíl i při aktualizaci různých oddílů. Explicitně stanovte oddělení v podmínkách provozu.

// Problem: Condition can scan the entire table
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

// Solution: Add explicit partition filters
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + date + "' AND t.country = '" + country + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

Výjimky při konfliktech

Když dojde ke konfliktu transakcí, zjistíte jednu z následujících výjimek:

Výjimka při souběžném připojování

Tato výjimka nastane, když souběžná operace přidá soubory ve stejném oddílu (nebo kdekoli v tabulce bez oddílů), který vaše operace přečte. Doplňky souborů můžou být způsobeny operacemi INSERT, DELETE, UPDATE, nebo MERGE operacemi.

Při výchozí úrovni izolace WriteSerializable nejsou soubory přidané operacemi INSERT, které přidávají data, aniž by četly jakákoli data, v konfliktu s žádnou operací. Pokud je úroveň izolace Serializable, jakékoli operace přidání mohou způsobit konflikt.

Důležité

Konflikt může nastat i v režimu WriteSerializable, pokud více současných DELETEUPDATE, , nebo MERGE operací může odkazovat na hodnoty připojené operací.INSERT Operace DELETE, UPDATE, nebo MERGE je ta, která selže, protože čte připojená data. Chcete-li se tomu vyhnout:

  • Zajistěte, aby souběžné operace DELETE, UPDATE nebo MERGE nečetly přidaná data.
  • Mít maximálně jednu DELETE, UPDATEnebo MERGE operaci, která může číst připojená data

ConcurrentDeleteReadException

K této výjimce dochází, když souběžná operace odstraní soubor, který operace přečte. Mezi běžné příčiny patří DELETE, UPDATE nebo MERGE operace, které přepisují soubory.

ConcurrentDeleteDeleteException

K této výjimce dochází, když souběžná operace odstraní také soubor, který vaše operace odstraní. Příčinou můžou být dvě souběžné operace komprimace, které přepisují stejné soubory.

MetadataChangedException

Tato výjimka nastává, když současná transakce aktualizuje metadata tabulky Delta Lake. Mezi běžné příčiny patří ALTER TABLE operace nebo zápisy, které aktualizují schéma tabulky.

VýjimkaSoučasnýchTransakcí

Tato výjimka nastává, pokud je streamovaný dotaz používající stejnou polohu kontrolního bodu zahájen několikrát současně a snaží se zapsat do tabulky Delta Lake současně. Nikdy současně neprovozujte dva streamovací dotazy se stejným umístěním kontrolního bodu.

VýjimkaZměnaProtokolu

K této výjimce může dojít v těchto případech:

  • Vaše tabulka Delta Lake se upgraduje na novou verzi protokolu (možná budete muset upgradovat databricks Runtime).
  • Více zapisovačů vytváří nebo nahrazuje tabulku ve stejnou dobu.
  • Více zapisovačů zapisuje současně na prázdnou cestu k souboru.

Viz kompatibilita a protokoly funkcí Delta Lake.

Chování starší verze souběžnosti na úrovni řádků

V Databricks Runtime 13.3 LTS používá souběžnost na úrovni řádků starší způsob chování:

  • Vyžaduje vektory odstranění. Podívejte se na vektory odstranění v Databricks.
  • Tabulky s technologií Liquid Clustering automaticky povolují souběžný přístup na úrovni řádků.

Další zdroje informací

  • Last updated on