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 radnivå-samtidighet visar följande tabell hur varje par av samtidiga skrivoperationer beter sig på varje isoleringsnivå.

Samtidiga metadataändringar är ett undantag från varje resultat i tabellen. En metadataförändring, såsom ett ALTER TABLE kommando eller en skrivning som uppdaterar tabellschemat, kan orsaka att alla samtidiga skrivoperationer misslyckas, inklusive INSERT. Se Metadata-förändringskonflikter.

Operationspar WriteSerializable (standard) Serialiserbar
INSERT (1) + INSERT Kan inte konfliktera Kan inte konfliktera
INSERT + UPDATE, RADERA, MERGE INTO Kan inte konfliktera Kan vara i konflikt när samma rad ändras. , UPDATEDELETE, eller MERGE operationen misslyckas, inte INSERT.
INSERT + OPTIMIZE Kan inte konfliktera Kan inte konfliktera
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Kan konflikter när man ändrar samma rad Kan konflikter när man ändrar samma rad
UPDATE, DELETE, MERGE INTO + OPTIMIZE 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.
OPTIMIZE + OPTIMIZE 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

  • När ett par kan konflikta misslyckas endast operationen som läser de berörda datana. An INSERT som lägger till data utan att läsa tabellen är inte operationen som misslyckas, så retry-logiken hör hemma på den samtidiga UPDATE, DELETE, eller MERGE.
  • 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 radnivå-samtidighet visar följande tabell hur varje par samtidiga skrivoperationer beter sig på varje isoleringsnivå.

Samtidiga metadataändringar är ett undantag från varje resultat i tabellen. En metadataförändring, såsom ett ALTER TABLE kommando eller en skrivning som uppdaterar tabellschemat, kan orsaka att alla samtidiga skrivoperationer misslyckas, inklusive INSERT. Se Metadata-förändringskonflikter.

Operationspar WriteSerializable (standard) Serialiserbar
INSERT (1) + INSERT Kan inte konfliktera Kan inte konfliktera
INSERT + UPDATE, RADERA, MERGE INTO Kan inte konfliktera Kan konflikt. , UPDATEDELETE, eller MERGE operationen misslyckas, inte INSERT. Se Undvik konflikter med partitionering.
INSERT + OPTIMIZE Kan inte konfliktera Kan inte konfliktera
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Kan konflikt. Se Undvik konflikter med partitionering. Kan konflikt. Se Undvik konflikter med partitionering.
UPDATE, DELETE, MERGE INTO + OPTIMIZE 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.
OPTIMIZE + OPTIMIZE 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

  • När ett par kan konflikta misslyckas endast operationen som läser de berörda datana. An INSERT som lägger till data utan att läsa tabellen är inte operationen som misslyckas, så retry-logiken hör hemma på den samtidiga UPDATE, DELETE, eller MERGE.
  • 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!

En konflikt kan fortfarande uppstå i WriteSerializable-läget om flera samtidiga DELETE, UPDATE, eller MERGE operationer kan referera till värden som lagts till av en INSERT operation. Operationen DELETE, UPDATE, eller MERGE är den som misslyckas, eftersom den läser de tillagda datana. 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

Detta undantag uppstår när en samtidig transaktion uppdaterar metadata i en Delta Lake-tabell. Vanliga orsaker är ALTER TABLE åtgärder eller skrivningar som uppdaterar tabellschemat.

ConcurrentTransactionException

Detta undantag uppstår om en strömmande fråga som använder samma kontrollpunkt startas flera gånger samtidigt och försöker skriva till Delta Lake-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