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.

Zonder gelijktijdige toegang op rijniveau kunnen twee gelijktijdige bewerkingen conflicteren wanneer ze dezelfde databestanden wijzigen, zelfs als ze verschillende rijen veranderen. Dit veroorzaakt mislukkingen in workloads zoals gelijktijdige MERGE, UPDATE, of DELETE taken tegen dezelfde tabel. Zie Schrijfconflicten zonder gelijktijdigheid op rijniveau.

Vereisten voor gelijktijdigheid op rijniveau

Gelijktijdigheid op rijniveau wordt automatisch ingeschakeld wanneer aan al deze vereisten is 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 gelijktijdigheid op rijniveau toont de volgende tabel hoe elk paar gelijktijdige schrijfbewerkingen zich gedraagt in elk isolatieniveau.

Gelijktijdige wijzigingen in metadata vormen een uitzondering op alle resultaten in de tabel. Een wijziging in metadata, zoals een ALTER TABLE commando of een schrijfbewerking die het tabelschema bijwerkt, kan ervoor zorgen dat alle gelijktijdige schrijfbewerkingen falen, inclusief INSERT. Zie conflicten bij metagegevenswijzigingen.

Bewerkingspaar 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, DELETE of MERGE operatie faalt, niet de INSERT.
INSERT + OPTIMIZE Kan niet conflicteren Kan niet conflicteren
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Kan conflicteren bij het aanpassen van dezelfde rij Er kan een conflict ontstaan 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 vormen een uitzondering voor alle resultaten in de tabel. Een wijziging in metadata, zoals een ALTER TABLE-commando of een schrijfbewerking die het tabelschema bijwerkt, kan ervoor zorgen dat alle gelijktijdige schrijfbewerkingen falen, inclusief INSERT. Zie conflicten met veranderingen in metadata.

Bewerkingspaar WriteSerializable (standaard) Serialiseerbaar
INSERT (1) + INSERT Kan niet conflicteren Kan niet conflicteren
INSERT + UPDATE, VERWIJDEREN, MERGE INTO Kan niet conflicteren Kan conflicteren. De bewerking UPDATE, DELETE of MERGE mislukt, niet de INSERT. Zie Conflicten voorkomen met behulp van partitionering.
INSERT + OPTIMIZE Kan niet conflicteren Kan niet conflicteren
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Kan conflicteren. Zie Conflicten voorkomen met behulp van partitionering. Kan conflicteren. 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 deze operaties volgt conflictoplossing de normale gelijktijdigheidsafhandeling 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, observeer je een van deze 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 bestandstoevoegingen kunnen worden veroorzaakt door INSERT, DELETE, UPDATE, of MERGE 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 kunnen verwijzen naar waarden 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

  • Laatst bijgewerkt om