Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Le transazioni di database forniscono un modello di programmazione sicuro e prevedibile per gestire le modifiche simultanee ai dati. I database relazionali tradizionali, ad esempio SQL Server, consentono di scrivere la logica di business usando stored procedure e trigger e quindi di inviarli al server per l'esecuzione direttamente all'interno del motore di database.
Con i database relazionali tradizionali, è necessario gestire due linguaggi di programmazione diversi: un linguaggio di programmazione non transazionale, ad esempio JavaScript, Python, C# o Java; e un linguaggio di programmazione transazionale, ad esempio T-SQL, eseguito in modo nativo dal database.
Il motore di database in Azure Cosmos DB supporta transazioni conformi agli standard ACID completi (atomicità, coerenza, isolamento, durabilità) con isolamento a livello di snapshot. Tutte le operazioni di database all'interno dell'ambito della partizione logica di un contenitore vengono eseguite in modo transazionale all'interno del motore di database ospitato dalla replica della partizione. Queste operazioni includono sia la scrittura (l'aggiornamento di uno o più elementi all'interno della partizione logica) sia le operazioni di lettura.
Nella tabella seguente sono elencati i diversi tipi di operazioni e transazioni:
| Operation | Tipo di operazione | Transazione a singolo o multi-elemento |
|---|---|---|
| Inserisci (senza un trigger di pre/post) | Scrittura | Transazione a singolo elemento |
| Inserisci (con un attivatore pre/post) | Scrivere e leggere | Transazione a più elementi |
| Sostituisci (senza un trigger di pre/post) | Scrittura | Transazione a singolo elemento |
| Sostituire (usando un trigger di pre/post) | Scrivere e leggere | Transazione a più elementi |
| Upsert (senza un trigger di pre/post) | Scrittura | Transazione a singolo elemento |
| Upsert (con un trigger di pre/post) | Scrivere e leggere | Transazione a più elementi |
| Elimina (senza un trigger di pre/post) | Scrittura | Transazione a singolo elemento |
| Elimina (con un trigger pre/post) | Scrivere e leggere | Transazione a più elementi |
| Eseguire una stored procedure | Scrivere e leggere | Transazione a più elementi |
| Esecuzione avviata dal sistema di una routine di merge | Scrittura | Transazione a più elementi |
| Esecuzione avviata dal sistema dell'eliminazione di elementi in base alla scadenza (TTL) di un elemento | Scrittura | Transazione a più elementi |
| Leggi | Leggi | Transazione a singolo elemento |
| Feed di modifiche | Leggi | Transazione a più elementi |
| Lettura impaginata | Leggi | Transazione a più elementi |
| Query impaginata | Leggi | Transazione a più elementi |
| Eseguire l'UDF come parte di una query paginata | Leggi | Transazione a più elementi |
Transazioni di più elementi
Azure Cosmos DB consente di scrivere stored procedure, trigger e funzioni definite dall'utente e di combinare procedure in JavaScript. Azure Cosmos DB supporta in modo nativo l'esecuzione di JavaScript all'interno del motore di database. È possibile registrare stored procedure, trigger pre/post, funzioni definite dall'utente e procedure di unione in un contenitore e successivamente eseguirle in modo transazionale all'interno del motore di database di Azure Cosmos DB. La scrittura della logica dell'applicazione in JavaScript consente l'espressione naturale del flusso di controllo, la definizione dell'ambito, l'assegnazione e l'integrazione delle primitive di gestione delle eccezioni all'interno delle transazioni di database direttamente nel linguaggio JavaScript.
Le stored procedure basate su JavaScript, i trigger, le funzioni definite dall'utente e le procedure di merge vengono incluse in una transazione ACID ambientale con isolamento dello snapshot per tutti gli elementi all'interno della partizione logica. Durante l'esecuzione, se il programma JavaScript genera un'eccezione, l'intera transazione viene interrotta e viene eseguito il rollback. Il modello di programmazione risultante è semplice ma potente. Gli sviluppatori JavaScript ottengono un modello di programmazione durevole, pur usando i costrutti di linguaggio e le primitive della libreria familiari.
La possibilità di eseguire JavaScript direttamente all'interno del motore di database offre prestazioni ed esecuzione transazionale delle operazioni di database sugli elementi di un contenitore. Inoltre, poiché il motore di database di Azure Cosmos DB supporta nativamente JSON e JavaScript, non c'è alcuna impedenza tra i sistemi di tipi di un'applicazione e il database.
Controllo della concorrenza ottimistica
Il controllo della concorrenza ottimistica (OCC) consente di evitare la perdita di aggiornamenti ed eliminazioni. Le operazioni in conflitto simultanee vengono sottoposte al normale blocco pessimistico del motore di database ospitato dalla partizione logica proprietaria dell'elemento. Quando due operazioni simultanee tentano di aggiornare la versione più recente di un elemento all'interno di una partizione logica, una di esse vince e l'altra ha esito negativo. Tuttavia, se una o due operazioni che tentano di aggiornare contemporaneamente lo stesso elemento aveva letto in precedenza un valore precedente dell'elemento, il database non sa se il valore letto in precedenza da una o entrambe le operazioni in conflitto era effettivamente il valore più recente dell'elemento.
Fortunatamente, questa situazione può essere rilevata con OCC prima di consentire alle due operazioni di immettere il limite della transazione all'interno del motore di database. OCC protegge i dati dalla sovrascrittura accidentale delle modifiche apportate da altri utenti. Impedisce inoltre ad altri di sovrascrivere accidentalmente le proprie modifiche.
Implementare il controllo della concorrenza ottimistica utilizzando ETag e le intestazioni HTTP
Ogni elemento archiviato in un contenitore di Azure Cosmos DB ha una proprietà definita _etag dal sistema. Il valore di _etag viene generato e aggiornato automaticamente dal server ogni volta che l'elemento viene aggiornato.
_etag può essere utilizzato con l'intestazione della richiesta fornita if-match dal client per consentire al server di decidere se un elemento può essere aggiornato in modo condizionale. Se il valore dell'intestazione if-match corrisponde al valore di _etag nel server, l'elemento viene quindi aggiornato. Se il valore dell'intestazione della if-match richiesta non è più corrente, il server rifiuta l'operazione con un messaggio di risposta "ERRORE precondizione HTTP 412". Il client può quindi recuperare l'elemento per ottenere la versione corrente dell'elemento sul server o eseguire l'override della versione dell'elemento sul server con il proprio valore _etag per l'elemento. Inoltre, _etag può essere usato con l'intestazione if-none-match per determinare se è necessario un refetch di una risorsa.
Il valore dell'elemento _etag cambia ogni volta che l'elemento viene aggiornato. Per le operazioni di sostituzione degli elementi, if-match deve essere espressa in modo esplicito come parte delle opzioni della richiesta. Per un esempio, vedere il codice di esempio in GitHub. I _etag valori vengono controllati in modo implicito per tutti gli elementi scritti modificati dalla procedura memorizzata. Se viene rilevato un conflitto, la stored procedure annulla la transazione e genera un'eccezione. Con questo metodo, tutte o nessuna delle operazioni di scrittura all'interno della stored procedure vengono applicate in modo atomico. Si tratta di un segnale all'applicazione per riapplicare gli aggiornamenti e ripetere la richiesta client originale.
Controllo della concorrenza ottimistica e distribuzione globale
Gli aggiornamenti simultanei di un elemento vengono sottoposti al protocollo OCC dal livello del protocollo di comunicazione di Azure Cosmos DB. Per gli account Azure Cosmos DB configurati per le scritture a singola area, Azure Cosmos DB garantisce che la versione lato client dell'elemento che si sta aggiornando (o eliminando) corrisponda alla versione dell'elemento nel contenitore Azure Cosmos DB. Ciò garantisce che le operazioni di scrittura siano protette dal rischio di essere sovrascritte accidentalmente dalle operazioni di scrittura di altri utenti e viceversa. In un ambiente multiutente, il controllo della concorrenza ottimistica consente di evitare l'eliminazione accidentale o l'aggiornamento della versione errata di un elemento. Di conseguenza, gli elementi sono protetti dai problemi infami di "aggiornamento perso" o "eliminazione persa".
In un account Azure Cosmos DB configurato con scritture multi-regione, è possibile eseguire il commit dei dati in modo indipendente nelle aree secondarie se le _etag corrispondono a quelle dei dati nell'area locale. Una volta eseguito il commit dei nuovi dati in locale in un'area secondaria, viene quindi unito nell'hub o nell'area primaria. Se la politica di risoluzione dei conflitti unisce i nuovi dati nell'area dell'hub, questi dati vengono replicati a livello globale con il nuovo _etag. Se i criteri di risoluzione dei conflitti rifiutano i nuovi dati, viene eseguito il rollback dell'area secondaria ai dati originali e _etag.
Passaggi successivi
Altre informazioni sulle transazioni di database e sul controllo della concorrenza ottimistica: