Concorrenza a livello di riga

La concorrenza a livello di riga riduce i conflitti tra le operazioni di scrittura simultanee rilevando le modifiche a livello di riga e risolvendo automaticamente i conflitti che si verificano quando si scrive simultaneamente l'aggiornamento o si eliminano righe diverse nello stesso file di dati.

Requisiti per la concorrenza a livello di riga

La concorrenza a livello di riga viene abilitata automaticamente quando vengono soddisfatti tutti i requisiti seguenti:

• Uso di Databricks Runtime 14.3 LTS e versioni successive.
• La tabella di origine non usa partizioni.
• Nella tabella di origine sono abilitati vettori di eliminazione. Vedere Vettori di eliminazione in Databricks.

Le tabelle partizionate non consentono la concorrenza a livello di riga. Tuttavia, quando i vettori di eliminazione sono abilitati, le tabelle partizionate possono comunque evitare conflitti tra OPTIMIZE e le operazioni di scrittura. Vedere Limitazioni per la concorrenza a livello di riga.

Per le versioni di Databricks Runtime precedenti alla versione 14.3 LTS, vedere Comportamento precedente della concorrenza a livello di riga.

Matrice di conflitti con concorrenza a livello di riga

Per le tabelle sorgente con concorrenza a livello di riga, la tabella seguente mostra come si comporta ogni coppia di operazioni di scrittura concorrente in ciascun livello di isolamento.

I cambiamenti simultanei nei metadati sono un'eccezione per ogni risultato nella tabella. Un cambiamento di metadati, come un ALTER TABLE comando o una scrittura che aggiorna lo schema della tabella, potrebbe causare il fallimento di tutte le operazioni di scrittura concorrente, incluso INSERT. Vedi Conflitti di cambiamenti dei metadati.

(1) Tutte le INSERT operazioni in questa tabella indicano operazioni di inserimento in append che non contengono subquery che leggono dati dalla stessa tabella. INSERT le operazioni contenenti sottoquery che leggono dalla stessa tabella garantiscono lo stesso livello di concorrenza di MERGE.

Conflitti di scrittura senza concorrenza a livello di riga

Per le tabelle sorgente senza concorrenza a livello di riga, la seguente tabella mostra come si comporta ogni coppia di operazioni di scrittura concorrenti in ciascun livello di isolamento.

I cambiamenti simultanei nei metadati sono un'eccezione per ogni risultato nella tabella. Un cambiamento di metadati, come un ALTER TABLE comando o una scrittura che aggiorna lo schema della tabella, potrebbe causare il fallimento di tutte le operazioni di scrittura concorrente, incluso INSERT. Vedi Conflitti di cambiamenti dei metadati.

(1) Tutte le INSERT operazioni in questa tabella indicano operazioni di inserimento in append che non contengono subquery che leggono dati dalla stessa tabella. INSERT le operazioni contenenti sottoquery che leggono dalla stessa tabella garantiscono lo stesso livello di concorrenza di MERGE.

Limitazioni per la concorrenza a livello di riga

Le limitazioni si applicano per la concorrenza a livello di riga. Per le operazioni seguenti, la risoluzione dei conflitti segue la normale concorrenza per i conflitti di scrittura. Consultare Conflitti di scrittura senza concorrenza a livello di riga.

Si applicano anche tutte le limitazioni per i vettori di eliminazione. Vedere Limitazioni.

Evitare conflitti usando il partizionamento

Per tutti i casi contrassegnati come "possono essere in conflitto" nelle matrici di conflitti, si verifica un conflitto solo se le due operazioni influiscono sullo stesso set di file. Per rendere disgiunti due set di file, partizionare la tabella in base alle stesse colonne utilizzate nelle condizioni operative.

Esempio:

I comandi UPDATE table WHERE date > '2010-01-01' ... e DELETE table WHERE date < '2010-01-01' confliggono se la tabella non è partizionata per data, perché entrambi possono tentare di modificare gli stessi file. Il partizionamento della tabella mediante date evita il conflitto.

Evitare conflitti con filtri di partizione espliciti

Questa eccezione viene spesso generata durante operazioni simultanee DELETE, UPDATE, o MERGE che potrebbero leggere la stessa partizione anche quando si aggiornano partizioni diverse. Rendere esplicita la separazione nella condizione dell'operazione:

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

Eccezioni di conflitto

Quando si verifica un conflitto di transazioni, si osserva una delle eccezioni seguenti:

ConcurrentAppendException

Questa eccezione si verifica quando un'operazione simultanea aggiunge file nella stessa partizione (o in qualsiasi punto di una tabella non partizionata) letti dall'operazione. Le aggiunte di file possono essere causate da INSERT, DELETE, UPDATE o MERGE operazioni.

Con il livello di isolamento WriteSerializable predefinito, i file aggiunti dalle INSERT operazioni che aggiungono dati senza leggere dati non sono in conflitto con alcuna operazione. Se il livello di isolamento è serializzabile, eventuali accodamenti possono entrare in conflitto.

ConcurrentDeleteReadException

Questa eccezione si verifica quando un'operazione simultanea elimina un file letto dall'operazione. Le cause comuni sono DELETE, UPDATE o MERGE, operazioni che riscrivono i file.

ConcurrentDeleteDeleteException

Questa eccezione si verifica quando un'operazione simultanea elimina un file eliminato anche dall'operazione. Ciò potrebbe essere causato da due operazioni di compattazione simultanee che riscrivono gli stessi file.

MetadataChangedException

Questa eccezione si verifica quando una transazione concorrente aggiorna i metadati di una tabella Delta Lake. Le cause comuni sono ALTER TABLE operazioni o scritture che aggiornano lo schema della tabella.

EccezioneDiTransazioneConcorrenziale

Questa eccezione si verifica se una query streaming che utilizza la stessa posizione del checkpoint viene avviata più volte contemporaneamente e cerca di scrivere contemporaneamente nella tabella Delta Lake. Non eseguire mai due query di streaming con la stessa posizione del checkpoint contemporaneamente.

ProtocolChangedException

Questa eccezione può verificarsi quando:

• La tabella Delta Lake viene aggiornata a una nuova versione del protocollo (potrebbe essere necessario aggiornare Databricks Runtime)
• Più writer stanno creando o sostituendo una tabella contemporaneamente
• Più scrittori stanno scrivendo in un percorso vuoto contemporaneamente

Vedere Compatibilità e protocolli delle funzionalità delta Lake.

Comportamento precedente della concorrenza a livello di riga

In Databricks Runtime 13.3 LTS, la concorrenza a livello di riga utilizza il comportamento legacy:

• Richiede vettori di eliminazione. Vedere Vettori di eliminazione in Databricks.
• Le tabelle con clustering liquido abilitano automaticamente la concorrenza a livello di riga.

Risorse aggiuntive

• Livelli di isolamento (WriteSerializable e Serializable)
• Transazioni
• Vettori di eliminazione in Databricks
• Compatibilità e protocolli delle funzionalità Delta Lake