Dela via

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å

Tabeller stöder inte samtidighet på radnivå om de har partitioner definierade eller inte har borttagningsvektorer aktiverade. Samtidighet på radnivå kräver Databricks Runtime 14.2 och senare.

Tabeller med partitioner stöder inte samtidighet på radnivå, men kan fortfarande undvika konflikter mellan OPTIMIZE och alla andra skrivåtgärder när borttagningsvektorer är aktiverade. Se Begränsningar för samtidighet på radnivå.

Information om Databricks Runtime-versioner före 14.2 finns i Beteende för samtidighetsförhandsvisning på radnivå (äldre).

Anmärkning

MERGE INTO stöd för samtidighet på radnivå kräver Photon i Databricks Runtime 14.2. I Databricks Runtime 14.3 LTS och senare krävs inte Photon.

Konfliktmatris med samtidighet på radnivå

I följande tabell visas vilka par med skrivåtgärder som kan vara i konflikt på varje isoleringsnivå med samtidighet på radnivå aktiverat:

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 läser några data från samma tabell innan de genomför. INSERT åtgärder som innehåller underfrågor som läser samma tabell stöder samma samtidighet som MERGE.

Anmärkning

  • Tabeller med identitetskolumner stöder inte samtidiga transaktioner. Se Använda identitetskolumner i Delta Lake.
  • 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å

Tabeller stöder inte samtidighet på radnivå om de har partitioner definierade eller inte har borttagningsvektorer aktiverade. Databricks Runtime 14.2 eller senare krävs för samtidighet på radnivå.

Konfliktmatris utan samtidighet på radnivå

I följande tabell visas vilka par med skrivåtgärder som kan vara i konflikt på varje isoleringsnivå:

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 läser några data från samma tabell innan de genomför. INSERT åtgärder som innehåller underfrågor som läser samma tabell stöder samma samtidighet som MERGE.

Anmärkning

  • Tabeller med identitetskolumner stöder inte samtidiga transaktioner. Se Använda identitetskolumner i Delta Lake.
  • REORG operationer har isoleringssemantik som är identiska 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.

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.

Exempel: Undvika 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 standardnivån WriteSerializable konflikterar inte filer som läggs till av blinda INSERT åtgärder (åtgärder som lägger till data utan att läsa några data) med någon åtgärd. Om isoleringsnivån är Serializable kan blinda bifogningar skapa konflikter.

Viktigt!

Blinda tillägg kan vara i konflikt i WriteSerializable-läge om flera samtidiga DELETE, UPDATEeller MERGE åtgärder kan referera till värden som infogas av blinda tillägg. 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-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.

Förhandsversionbeteende för samtidighet på radnivå (äldre)

I det här avsnittet beskrivs förhandsgranskningsbeteenden för samtidighet på radnivå i Databricks Runtime 14.1 och nedan.

Databricks Runtime-version Beteende
Databricks Runtime 13.3 LTS och senare Tabeller med flytande klustring aktiverar automatiskt samtidighet på radnivå
Databricks Runtime 14.0 och 14.1 Aktivera samtidighet på radnivå för tabeller med borttagningsvektorer med hjälp av konfigurationen nedan
Databricks Runtime 14.1 och nedan Icke-photonberäkning supporterar endast samtidighet på radnivå för DELETE operationer

Så här aktiverar du samtidighet på radnivå i Databricks Runtime 14.0 och 14.1:

spark.databricks.delta.rowLevelConcurrencyPreview = true

Samtidighet på radnivå kräver alltid borttagningsvektorer.

Nästa steg

  • Last updated on