Konkurrensförmåga på radnivå

Samtidighet på radnivå minskar konflikterna mellan samtidiga skrivåtgärder genom att identifiera ändringar på radnivå och automatiskt lösa konflikter som uppstår när samtidiga skrivningar uppdaterar eller tar bort olika rader i samma datafil.

Krav för samtidighet på radnivå

Samtidighet på radnivå aktiveras automatiskt när alla följande krav uppfylls:

  • Använda Databricks Runtime 14.3 LTS och senare.
  • Källtabellen använder inte partitioner.
  • Källtabellen har borttagningsvektorer aktiverade. Se Borttagningsvektorer i Databricks.

Partitionerade tabeller tillåter inte samtidighet på radnivå. Men när borttagningsvektorer är aktiverade kan partitionerade tabeller fortfarande undvika konflikter mellan OPTIMIZE och skrivåtgärder. Se Begränsningar för samtidighet på radnivå.

För Databricks Runtime-versioner före 14.3 LTS, se Äldre beteende för samtidighet på radnivå.

Konfliktmatris med samtidighet på radnivå

För källtabeller med samtidighet på radnivå visar följande tabell vilka par med skrivåtgärder som kan vara i konflikt på varje isoleringsnivå:

Operation INSERT (1) UPDATE, TA BORT, MERGE INTO OPTIMIZE
INSERT Kan inte konfliktera
UPDATE, TA BORT, MERGE INTO Det går inte att komma i konflikt med WriteSerializable. Kan vara i konflikt i Serializable när du ändrar samma rad. Kan vara i konflikt när samma rad ändras.
OPTIMIZE Kan inte konfliktera Kan vara i konflikt när ZORDER BY används. Det går inte att komma i konflikt med något annat. Kan vara i konflikt när ZORDER BY används. Det går inte att komma i konflikt med något annat.

(1) Alla INSERT åtgärder i den här tabellen beskriver tilläggsåtgärder som inte innehåller underfrågor som läser data från samma tabell. INSERT operationer som innehåller underfrågor som läser från samma tabell stöder samma samtidighet som MERGE.

Anmärkning

  • Tabeller med identitetskolumner stöder inte samtidiga transaktioner. Se Identitetskolumner.
  • REORG operationer har isoleringssemantik identisk med OPTIMIZE när datafiler skrivs om. När du använder REORG för att tillämpa en uppgradering ändras tabellprotokollen, vilket står i konflikt med alla pågående åtgärder.

Skrivkonflikter utan samtidighet på radnivå

För källtabeller utan samtidighet på radnivå visar följande tabell vilka par med skrivåtgärder som kan vara i konflikt på varje isoleringsnivå:

Operation INSERT (1) UPDATE, TA BORT, MERGE INTO OPTIMIZE
INSERT Kan inte konfliktera
UPDATE, TA BORT, MERGE INTO Det går inte att komma i konflikt med WriteSerializable. Kan orsaka konflikt i Serializable. Se Undvik konflikter med partitionering. Kan vara i konflikt med Serializable och WriteSerializable. Se Undvik konflikter med partitionering.
OPTIMIZE Kan inte konfliktera Det går inte att komma i konflikt med tabeller med borttagningsvektorer aktiverade, såvida inte ZORDER BY används. Kan annars leda till konflikt. Det går inte att komma i konflikt med tabeller med borttagningsvektorer aktiverade, såvida inte ZORDER BY används. Kan annars leda till konflikt.

(1) Alla INSERT åtgärder i den här tabellen beskriver tilläggsåtgärder som inte innehåller underfrågor som läser data från samma tabell. INSERT operationer som innehåller underfrågor som läser från samma tabell stöder samma samtidighet som MERGE.

Anmärkning

  • Tabeller med identitetskolumner stöder inte samtidiga transaktioner. Se Identitetskolumner.
  • REORG operationer har isoleringssemantik identisk med OPTIMIZE när datafiler skrivs om. När du använder REORG för att tillämpa en uppgradering ändras tabellprotokollen och är i konflikt med alla pågående åtgärder.

Begränsningar för samtidighet på radnivå

Begränsningar gäller för samtidighet på radnivå. För följande operationer använder konfliktlösning den vanliga samtidighetsmetoden för skrivkonflikter. Se Skriva konflikter utan samtidighet på radnivå.

Limitation Beskrivning
Komplexa villkorssatser Villkor för komplexa datatyper (structs, matriser, kartor), icke-deterministiska uttryck, underfrågor och korrelerade underfrågor
MERGE predikatkrav I Databricks Runtime 14.2 MERGE måste kommandon använda ett explicit predikat i måltabellen för att filtrera rader som matchar källtabellen
Prestandaavvägning Konfliktdetektering på radnivå kan leda till längre total körningstid. Med många samtidiga transaktioner prioriterar författaren svarstiden framför konfliktlösning

Alla begränsningar för borttagningsvektorer gäller också. Se Begränsningar.

Undvik konflikter med partitionering

För alla fall som har markerats som "kan vara i konflikt" i konfliktmatriserna uppstår en konflikt endast om de två åtgärderna påverkar samma uppsättning filer. Om du vill göra två uppsättningar filer åtskilda partitioneras tabellen med samma kolumner som används under driftsförhållanden.

Ett exempel:

Kommandon UPDATE table WHERE date > '2010-01-01' ... och DELETE table WHERE date < '2010-01-01' konflikterar när tabellen inte är partitionerad efter datum, eftersom båda kan försöka ändra samma filer. Att partitionera tabellen genom date undviker konflikten.

Anmärkning

Partitionering av en tabell efter en kolumn med hög kardinalitet kan leda till prestandaproblem på grund av det stora antalet underkataloger.

Undvik konflikter med explicita partitionsfilter

Det här undantaget utlöses ofta under samtidiga DELETE, UPDATEeller MERGE åtgärder som kan läsa samma partition även när olika partitioner uppdateras. Gör separationen explicit i åtgärdsvillkoret:

// 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()

Konfliktundantag

När en transaktionskonflikt inträffar ser du något av följande undantag:

ConcurrentAppendException

Det här undantaget inträffar när en samtidig åtgärd lägger till filer i samma partition (eller var som helst i en icke-partitionerad tabell) som åtgärden läser. Filtilläggen kan orsakas av INSERT, DELETE, UPDATEeller MERGE åtgärder.

Med standardisoleringsnivån WriteSerializable kommer filer som lagts till genom INSERT-åtgärder som lägger till data utan att läsa några data inte i konflikt med någon åtgärd. Om isoleringsnivån är Serializable kan eventuella tillägg vara i konflikt.

Viktigt!

INSERT åtgärder kan vara i konflikt i WriteSerializable-läge om flera samtidiga DELETE, UPDATEeller MERGE åtgärder kan referera till värden som läggs till av åtgärden INSERT . För att undvika detta:

  • Se till att samtidiga DELETE, UPDATEeller MERGE åtgärder inte läser de bifogade data
  • Ha högst en DELETE, UPDATEeller MERGE åtgärd som kan läsa de bifogade data

ConcurrentDeleteReadException

Det här undantaget inträffar när en samtidig åtgärd tar bort en fil som åtgärden läser. Vanliga orsaker är DELETE, UPDATEeller MERGE åtgärder som skriver om filer.

ConcurrentDeleteDeleteException

Det här undantaget inträffar när en samtidig åtgärd tar bort en fil som även åtgärden tar bort. Detta kan orsakas av två samtidiga komprimeringsåtgärder som skriver om samma filer.

MetadataChangedException

Det här undantaget inträffar när en samtidig transaktion uppdaterar metadata för en Delta-tabell. Vanliga orsaker är ALTER TABLE åtgärder eller skrivningar som uppdaterar tabellschemat.

ConcurrentTransactionException

Det här undantaget inträffar om en direktuppspelningsfråga som använder samma kontrollpunktsplats startas flera gånger samtidigt och försöker skriva till Delta-tabellen samtidigt. Kör aldrig två direktuppspelningsfrågor med samma kontrollpunktsplats samtidigt.

Protokollsändringsundantag

Det här undantaget kan inträffa när:

  • Delta Lake-tabellen uppgraderas till en ny protokollversion (du kan behöva uppgradera Din Databricks Runtime)
  • Flera skrivare skapar eller ersätter en tabell samtidigt
  • Flera skrivare skriver till en tom sökväg samtidigt

Se Delta Lake-funktionskompatibilitet och protokoll.

Äldre beteende för samtidighet på radnivå

I Databricks Runtime 13.3 LTS använder samtidighet på radnivå äldre beteende:

Ytterligare resurser

  • Last updated on