Concurrentie op rijniveau

Gelijktijdigheid op rijniveau vermindert conflicten tussen gelijktijdige schrijfbewerkingen door wijzigingen op rijniveau te detecteren en automatisch conflicten op te lossen die optreden wanneer gelijktijdige schrijfbewerkingen worden bijgewerkt of verschillende rijen in hetzelfde gegevensbestand worden verwijderd.

Vereisten voor gelijktijdigheid op rijniveau

Gelijktijdigheid op rijniveau wordt automatisch ingeschakeld wanneer aan alle volgende vereisten wordt voldaan:

  • Databricks Runtime 14.3 LTS en hoger gebruiken.
  • De brontabel maakt geen gebruik van partities.
  • In de brontabel zijn verwijderingsvectoren ingeschakeld. Zie Verwijderingsvectoren in Databricks.

Gepartitioneerde tabellen staan gelijktijdigheid op rijniveau niet toe. Wanneer verwijderingsvectoren echter zijn ingeschakeld, kunnen gepartitioneerde tabellen nog steeds conflicten tussen OPTIMIZE en schrijfbewerkingen voorkomen. Zie Beperkingen voor gelijktijdigheid op rijniveau.

Voor Databricks Runtime-versies ouder dan 14.3 LTS, zie verouderd gedrag voor gelijktijdigheid op rijniveau.

Conflictmatrix met concurrentie op rijniveau

Voor brontabellen met rijniveau-gelijktijdigheid toont de volgende tabel hoe elk paar gelijktijdige schrijfbewerkingen zich gedraagt in elk isolatieniveau.

Gelijktijdige wijzigingen in metadata zijn een uitzondering op elk resultaat in de tabel. Een wijziging in metadata, zoals een ALTER TABLE commando of een schrijf die het tabelschema bijwerkt, kan ervoor zorgen dat alle gelijktijdige schrijfbewerkingen falen, inclusief INSERT. Zie conflicten met veranderingen in metadata.

Operatiepaar WriteSerializable (standaard) Serialiseerbaar
INSERT (1) + INSERT Kan niet conflicteren Kan niet conflicteren
INSERT + UPDATE, VERWIJDEREN, MERGE INTO Kan niet conflicteren Kan conflicteren bij het wijzigen van dezelfde rij. De UPDATE, , of MERGE operatie faalt, niet de INSERTDELETE.
INSERT + OPTIMIZE Kan niet conflicteren Kan niet conflicteren
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Er kan conflicten bij het aanpassen van dezelfde rij Er kan conflicten bij het aanpassen van dezelfde rij
UPDATE, DELETE, MERGE INTO + OPTIMIZE Kan conflicteren wanneer ZORDER BY wordt gebruikt. Kan niet op een andere manier conflicteren. Kan conflicteren wanneer ZORDER BY wordt gebruikt. Kan niet op een andere manier conflicteren.
OPTIMIZE + OPTIMIZE Kan conflicteren wanneer ZORDER BY wordt gebruikt. Kan niet op een andere manier conflicteren. Kan conflicteren wanneer ZORDER BY wordt gebruikt. Kan niet op een andere manier conflicteren.

(1) Alle INSERT bewerkingen in deze tabel beschrijven toevoegbewerkingen die geen subquery's bevatten die gegevens uit dezelfde tabel lezen. INSERT bewerkingen met subquery's die uit dezelfde tabel lezen, ondersteunen dezelfde gelijktijdigheid als MERGE.

Opmerking

  • Wanneer een paar kan conflicteren, faalt alleen de bewerking die de getroffen gegevens leest. Een INSERT die data toevoegt zonder de tabel te lezen is niet de operatie die faalt, dus herprobeerlogica hoort op de gelijktijdige UPDATE, DELETE, of MERGE.
  • Tabellen met identiteitskolommen bieden geen ondersteuning voor gelijktijdige transacties. Zie Identiteitskolommen.
  • REORG bewerkingen hebben isolatiesemantiek die identiek is aan OPTIMIZE bij het herschrijven van gegevensbestanden. Wanneer u REORG een upgrade toepast, worden tabelprotocollen gewijzigd, wat conflicteert met alle lopende bewerkingen.

Schrijfconflicten zonder gelijktijdigheid op rijniveau

Voor brontabellen zonder rijniveau-gelijktijdigheid toont de volgende tabel hoe elk paar gelijktijdige schrijfbewerkingen zich gedraagt in elk isolatieniveau.

Gelijktijdige wijzigingen in metadata zijn een uitzondering op elk resultaat in de tabel. Een wijziging in metadata, zoals een ALTER TABLE commando of een schrijf die het tabelschema bijwerkt, kan ervoor zorgen dat alle gelijktijdige schrijfbewerkingen falen, inclusief INSERT. Zie conflicten met veranderingen in metadata.

Operatiepaar WriteSerializable (standaard) Serialiseerbaar
INSERT (1) + INSERT Kan niet conflicteren Kan niet conflicteren
INSERT + UPDATE, VERWIJDEREN, MERGE INTO Kan niet conflicteren Kan conflicten. De UPDATE, , of MERGE operatie faalt, niet de INSERTDELETE. Zie Conflicten voorkomen met behulp van partitionering.
INSERT + OPTIMIZE Kan niet conflicteren Kan niet conflicteren
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Kan conflicten. Zie Conflicten voorkomen met behulp van partitionering. Kan conflicten. Zie Conflicten voorkomen met behulp van partitionering.
UPDATE, DELETE, MERGE INTO + OPTIMIZE Kan niet conflicteren in tabellen waarvoor verwijderingsvectoren zijn ingeschakeld, tenzij ZORDER BY deze worden gebruikt. Kan anders tot conflicten leiden. Kan niet conflicteren in tabellen waarvoor verwijderingsvectoren zijn ingeschakeld, tenzij ZORDER BY deze worden gebruikt. Kan anders tot conflicten leiden.
OPTIMIZE + OPTIMIZE Kan niet conflicteren in tabellen waarvoor verwijderingsvectoren zijn ingeschakeld, tenzij ZORDER BY deze worden gebruikt. Kan anders tot conflicten leiden. Kan niet conflicteren in tabellen waarvoor verwijderingsvectoren zijn ingeschakeld, tenzij ZORDER BY deze worden gebruikt. Kan anders tot conflicten leiden.

(1) Alle INSERT bewerkingen in deze tabel beschrijven toevoegbewerkingen die geen subquery's bevatten die gegevens uit dezelfde tabel lezen. INSERT bewerkingen met subquery's die uit dezelfde tabel lezen, ondersteunen dezelfde gelijktijdigheid als MERGE.

Opmerking

  • Wanneer een paar kan conflicteren, faalt alleen de bewerking die de getroffen gegevens leest. Een INSERT die data toevoegt zonder de tabel te lezen is niet de operatie die faalt, dus herprobeerlogica hoort op de gelijktijdige UPDATE, DELETE, of MERGE.
  • Tabellen met identiteitskolommen bieden geen ondersteuning voor gelijktijdige transacties. Zie Identiteitskolommen.
  • REORG bewerkingen hebben isolatiesemantiek die identiek is aan OPTIMIZE bij het herschrijven van gegevensbestanden. Wanneer u REORG een upgrade toepast, worden tabelprotocollen gewijzigd en conflicteren met alle lopende bewerkingen.

Beperkingen voor gelijktijdigheid op rijniveau

Beperkingen gelden voor gelijktijdigheid op rijniveau. Voor de volgende bewerkingen volgt conflictoplossing de normale gelijktijdigheid voor schrijfconflicten. Zie Schrijfconflicten zonder gelijktijdigheid op rijniveau.

Beperking Beschrijving
Complexe voorwaardelijke componenten Voorwaarden voor complexe gegevenstypen (structs, matrices, kaarten), niet-deterministische expressies, subquery's en gecorreleerde subquery's
MERGE voorwaarde voor predicaat In Databricks Runtime 14.2 MERGE moeten opdrachten een expliciet predicaat in de doeltabel gebruiken om rijen te filteren die overeenkomen met de brontabel
Compromis tussen prestaties Conflictdetectie op rijniveau kan de totale uitvoeringstijd verhogen. Met veel gelijktijdige transacties geeft de schrijver prioriteit aan latentie ten opzichte van conflictoplossing

Alle beperkingen voor verwijderingsvectoren gelden ook. Zie Beperkingen.

Conflicten voorkomen met behulp van partitionering

Voor alle gevallen die zijn gemarkeerd als 'kan conflicteren' in de conflictmatrices, treedt er alleen een conflict op als de twee bewerkingen van invloed zijn op dezelfde set bestanden. Om twee sets bestanden van elkaar te scheiden, partitieer de tabel met dezelfde kolommen die worden gebruikt in de bewerkingsvoorwaarden.

Voorbeeld:

De opdrachten UPDATE table WHERE date > '2010-01-01' ... en DELETE table WHERE date < '2010-01-01' conflicten als de tabel niet is gepartitioneerd op datum, omdat beide kunnen proberen om dezelfde bestanden te wijzigen. Het partitioneren van de tabel door date het conflict te voorkomen.

Opmerking

Het partitioneren van een tabel op basis van een kolom met een hoge kardinaliteit kan leiden tot prestatieproblemen vanwege het grote aantal submappen.

Conflicten voorkomen met expliciete partitiefilters

Deze uitzondering wordt vaak opgeworpen tijdens gelijktijdige DELETE, UPDATE of MERGE-bewerkingen die mogelijk dezelfde partitie lezen, zelfs als er verschillende partities worden bijgewerkt. Maak de scheiding expliciet in de bewerkingsvoorwaarde:

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

Uitzonderingen bij conflicten

Wanneer er een transactieconflict optreedt, ziet u een van de volgende uitzonderingen:

ConcurrentAppendException

Deze uitzondering treedt op wanneer een gelijktijdige bewerking bestanden toevoegt in dezelfde partitie (of ergens in een niet-gepartitioneerde tabel) die uw bewerking leest. De bestands toevoegingen kunnen worden veroorzaakt doorINSERT, DELETEof UPDATEMERGE bewerkingen.

Met het standaardisolatieniveau WriteSerializable conflicteren bestanden die zijn toegevoegd door INSERT-bewerkingen die gegevens toevoegen zonder gegevens te lezen, met geen enkele bewerking. Als het isolatieniveau Serializable is, kunnen eventuele append-bewerkingen conflicteren.

Belangrijk

Een conflict kan nog steeds optreden in de WriteSerializable-modus als meerdere gelijktijdige DELETE, UPDATE, of MERGE bewerkingen waarden verwijzen die door een INSERT operatie zijn toegevoegd. De DELETE, UPDATE, of MERGE operatie is degene die faalt, omdat deze de toegevoegde gegevens leest. Ga als volgt te werk om dit te voorkomen:

  • Zorg ervoor dat gelijktijdige DELETE, UPDATEof MERGE bewerkingen de toegevoegde gegevens niet lezen
  • Maximaal één DELETE, UPDATEof MERGE bewerking die de toegevoegde gegevens kan lezen

ConcurrentDeleteReadException

Deze uitzondering treedt op wanneer een gelijktijdige bewerking een bestand verwijdert dat door uw bewerking wordt gelezen. Veelvoorkomende oorzaken zijn DELETE, UPDATEof MERGE bewerkingen die bestanden herschrijven.

ConcurrentDeleteDeleteException

Deze uitzondering treedt op wanneer een gelijktijdige bewerking een bestand verwijdert dat uw bewerking ook verwijdert. Dit kan worden veroorzaakt doordat twee gelijktijdige compressiebewerkingen dezelfde bestanden herschrijven.

MetadataChangedException

Deze uitzondering treedt op wanneer een gelijktijdige transactie de metadata van een Delta Lake-tabel bijwerkt. Veelvoorkomende oorzaken zijn ALTER TABLE bewerkingen of schrijfbewerkingen waarmee het tabelschema wordt bijgewerkt.

GelijktijdigeTransactieUitzondering

Deze uitzondering treedt op als een streamingquery die dezelfde checkpointlocatie gebruikt, meerdere keren gelijktijdig wordt gestart en tegelijkertijd probeert naar de Delta Lake-tabel te schrijven. Voer nooit tegelijkertijd twee streamingquery's uit met dezelfde controlepuntlocatie.

ProtocolChangedException

Deze uitzondering kan optreden wanneer:

  • Uw Delta Lake-tabel wordt bijgewerkt naar een nieuwe protocolversie (mogelijk moet u uw Databricks Runtime upgraden)
  • Meerdere schrijvers maken of vervangen tegelijkertijd een tabel
  • Meerdere schrijvers schrijven tegelijkertijd naar een leeg pad

Bekijk de compatibiliteit en protocollen van Delta Lake-functies.

Verouderd gedrag van concurrency op rijniveau

In Databricks Runtime 13.3 LTS maakt gelijktijdigheid op rijniveau gebruik van verouderd gedrag:

Aanvullende informatiebronnen

  • Last updated on