Delen via

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

Tabellen bieden geen ondersteuning voor gelijktijdigheid op rijniveau als er partities zijn gedefinieerd of als er geen verwijderingsvectoren zijn ingeschakeld. Gelijktijdigheid op rijniveau vereist Databricks Runtime 14.2 en hoger.

Tabellen met partities bieden geen ondersteuning voor gelijktijdigheid op rijniveau, maar kunnen nog steeds conflicten voorkomen tussen OPTIMIZE en alle andere schrijfbewerkingen wanneer verwijderingsvectoren zijn ingeschakeld. Zie Beperkingen voor gelijktijdigheid op rijniveau.

Zie voor Databricks Runtime-versies vóór versie 14.2 het gedrag van gelijktijdigheidsoverzicht op rijniveau (verouderd).

Opmerking

MERGE INTO ondersteuning voor gelijktijdigheid op rijniveau vereist Photon in Databricks Runtime 14.2. In Databricks Runtime 14.3 LTS en hoger is Photon niet vereist.

Conflictmatrix met concurrentie op rijniveau

In de volgende tabel ziet u welke paren schrijfbewerkingen in elk isolatieniveau kunnen conflicteren met gelijktijdigheid op rijniveau ingeschakeld:

INSERT (1) UPDATEVERWIJDEREN MERGE INTO OPTIMIZE
INSERT Kan niet conflicteren
UPDATEVERWIJDEREN MERGE INTO Kan niet conflicteren in WriteSerializable. Kan conflicteren in Serializeerbaar bij het wijzigen van dezelfde rij. Kan conflicteren bij het wijzigen van dezelfde rij.
OPTIMIZE Kan niet conflicteren 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 gegevens uit dezelfde tabel lezen voordat ze worden doorgevoerd. INSERT bewerkingen die subquery's bevatten die dezelfde tabel lezen, ondersteunen dezelfde gelijktijdigheid als MERGE.

Opmerking

  • Tabellen met identiteitskolommen bieden geen ondersteuning voor gelijktijdige transacties. Zie Identiteitskolommen gebruiken in Delta Lake.
  • 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 paralleliteit op rijniveau

Tabellen bieden geen ondersteuning voor gelijktijdigheid op rijniveau als er partities zijn gedefinieerd of als er geen verwijderingsvectoren zijn ingeschakeld. Databricks Runtime 14.2 of hoger is vereist voor gelijktijdigheid op rijniveau.

Conflictmatrix zonder concurrentie op rijniveau

In de volgende tabel ziet u welke paren schrijfbewerkingen in elk isolatieniveau kunnen conflicteren:

INSERT (1) UPDATEVERWIJDEREN MERGE INTO OPTIMIZE
INSERT Kan niet conflicteren
UPDATEVERWIJDEREN MERGE INTO Kan niet conflicteren in WriteSerializable. Kan conflicteren in het Serializable. Zie Conflicten voorkomen met behulp van partitionering. Kan conflicten veroorzaken in Serializable en WriteSerializable. Zie Conflicten voorkomen met behulp van partitionering.
OPTIMIZE Kan niet conflicteren 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 gegevens uit dezelfde tabel lezen voordat ze worden doorgevoerd. INSERT bewerkingen die subquery's bevatten die dezelfde tabel lezen, ondersteunen dezelfde gelijktijdigheid als MERGE.

Opmerking

  • Tabellen met identiteitskolommen bieden geen ondersteuning voor gelijktijdige transacties. Zie Identiteitskolommen gebruiken in Delta Lake.
  • 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.

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.

Voorbeeld: Conflicten met expliciete partitiefilters voorkomen

Deze uitzondering wordt vaak gegenereerd tijdens gelijktijdige DELETE, UPDATE of MERGE bewerkingen die mogelijk dezelfde partitie lezen, zelfs wanneer 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 worden toegevoegd door blinde INSERT bewerkingen (bewerkingen die gegevens toevoegen zonder gegevens te lezen) niet met enige bewerking. Als het isolatieniveau Serializeerbaar is, kunnen blinde toevoegingen conflicteren.

Belangrijk

Blinde toevoegbewerkingen kunnen conflicteren in de modus WriteSerializable als meerdere gelijktijdige DELETE, UPDATEof MERGE bewerkingen kunnen verwijzen naar waarden die zijn ingevoegd door blinde toevoegbewerkingen. 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 metagegevens van een Delta-tabel bijwerken. Veelvoorkomende oorzaken zijn ALTER TABLE bewerkingen of schrijfbewerkingen waarmee het tabelschema wordt bijgewerkt.

GelijktijdigeTransactieUitzondering

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

ProtocolChangedException

Deze uitzondering kan optreden wanneer:

  • Uw Delta-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.

Voorbeeldgedrag voor gelijktijdigheid op rijniveau (verouderd)

In deze sectie worden preview-gedragingen beschreven voor gelijktijdigheid op rijniveau in Databricks Runtime versie 14.1 en lager.

Databricks Runtime-versie Gedrag
Databricks Runtime 13.3 LTS en hoger Tabellen met liquide clustering schakelen automatisch gelijktijdigheid op rijniveau in
Databricks Runtime 14.0 en 14.1 Gelijktijdigheid op rijniveau inschakelen voor tabellen met verwijderingsvectoren met behulp van de onderstaande configuratie
Databricks Runtime versie 14.1 en lager Niet-Photon-berekening biedt alleen ondersteuning voor gelijktijdigheid op rijniveau voor DELETE bewerkingen

Gelijktijdigheid op rijniveau inschakelen in Databricks Runtime 14.0 en 14.1:

spark.databricks.delta.rowLevelConcurrencyPreview = true

Gelijktijdigheid op rijniveau vereist altijd verwijderingsvectoren.

Volgende stappen 

  • Last updated on