Řízení optimistické souběžnosti a transakce
PLATÍ PRO: 
NoSQL
Databázové transakce poskytují bezpečný a předvídatelný programovací model pro zpracování souběžných změn dat. Tradiční relační databáze, jako SQL Server, umožňují psát obchodní logiku pomocí uložených procedur nebo triggerů a odesílat ji na server k provedení přímo v databázovém stroji. U tradičních relačních databází musíte pracovat se dvěma různými programovacími jazyky ( ne transakčními) aplikačními programovacími jazyky, jako je JavaScript, Python, C#, Java atd. a transakční programovací jazyk (například T-SQL), který je nativně spouštěný databází.
Databázový stroj ve službě Azure Cosmos DB podporuje úplné transakce kompatibilní s acid (Atomicity, Consistency, Isolation, Durability) s izolací snímků. Všechny databázové operace v rámci oboru logického oddílu kontejneru se provádějí transakcí v rámci databázového stroje hostovaného replikou oddílu. Tyto operace zahrnují operace zápisu (aktualizace jedné nebo více položek v rámci logického oddílu) i operace čtení. Následující tabulka ukazuje různé operace a typy transakcí:
| Operace | Typ operace | Transakce s jednou nebo více položkami |
|---|---|---|
| Vložit (bez triggeru před/po) | Zápis | Transakce s jednou položkou |
| Vložení (s aktivační událostí před a po) | Zápis a čtení | Transakce s více položkami |
| Nahradit (bez předběžného a následného triggeru) | Zápis | Transakce s jednou položkou |
| Nahradit (s triggerem před a po) | Zápis a čtení | Transakce s více položkami |
| Upsert (bez triggeru před/po) | Zápis | Transakce s jednou položkou |
| Upsert (s aktivační událostí před a po) | Zápis a čtení | Transakce s více položkami |
| Odstranění (bez předběžného nebo následného triggeru) | Zápis | Transakce s jednou položkou |
| Odstranění (s aktivační událostí před a po) | Zápis a čtení | Transakce s více položkami |
| Spustit uloženou proceduru | Zápis a čtení | Transakce s více položkami |
| Systém inicioval spuštění procedury sloučení | Zápis | Transakce s více položkami |
| Systém inicioval spuštění odstranění položek na základě hodnoty TTL (vypršení platnosti) položky. | Zápis | Transakce s více položkami |
| Čtení | Čtení | Transakce s jednou položkou |
| Kanál změn | Read | Transakce s více položkami |
| Stránkované čtení | Read | Transakce s více položkami |
| Stránkovaný dotaz | Read | Transakce s více položkami |
| Spuštění funkce definované uživatelem jako součásti stránkovaného dotazu | Read | Transakce s více položkami |
Transakce s více položkami
Azure Cosmos DB umožňuje psát uložené procedury, předběžné a následné triggery, uživatelem definované funkce (UDF) a slučovat procedury v JavaScriptu. Azure Cosmos DB nativně podporuje spouštění JavaScriptu ve svém databázovém stroji. V kontejneru můžete zaregistrovat uložené procedury, předběžné a následné triggery, uživatelem definované funkce (UDF) a procedury sloučení a později je transakčním spuštěním v databázovém stroji Azure Cosmos DB. Psaní aplikační logiky v JavaScriptu umožňuje přirozené vyjádření toku řízení, určení rozsahu proměnných, přiřazení a integraci primitiv zpracování výjimek v rámci databázových transakcí přímo v jazyce JavaScript.
Uložené procedury, triggery, funkce definované uživatelem a slučovací procedury založené na JavaScriptu jsou zabalené do okolí transakce ACID s izolací snímků napříč všemi položkami v rámci logického oddílu. Pokud javascriptový program vyvolá výjimku, během jeho provádění se celá transakce přeruší a vrátí zpět. Výsledný programovací model je jednoduchý, ale výkonný. Vývojáři v JavaScriptu získají odolný programovací model a přitom stále používají známé jazykové konstrukty a primitiva knihoven.
Možnost spouštět JavaScript přímo v databázovém stroji zajišťuje výkon a transakční provádění databázových operací s položkami kontejneru. Vzhledem k tomu, že databázový stroj Azure Cosmos DB nativně podporuje JSON a JavaScript, neexistuje žádná neshoda impedance mezi systémy typů aplikace a databáze.
Řízení optimistické souběžnosti
Optimistické řízení souběžnosti umožňuje zabránit ztrátě aktualizací a odstranění. Souběžné konfliktní operace podléhají pravidelnému pesimistickému uzamčení databázového stroje hostovaného logickým oddílem, který položku vlastní. Když se dvě souběžné operace pokusí aktualizovat nejnovější verzi položky v rámci logického oddílu, jedna z nich vyhraje a druhá selže. Pokud však jedna nebo dvě operace, které se pokusily souběžně aktualizovat stejnou položku, dříve načetly starší hodnotu položky, databáze neví, jestli hodnota, kterou dříve načetla některá nebo obě konfliktní operace, byla skutečně nejnovější hodnotou položky. Naštěstí se tato situace dá zjistit pomocí optimistického řízení souběžnosti (OCC) před tím, než tyto dvě operace vstoupí do hranice transakce v databázovém stroji. OCC chrání vaše data před náhodným přepsáním změn provedených jinými uživateli. Brání také ostatním v tom, aby omylem přepsaly vaše vlastní změny.
Implementace optimistického řízení souběžnosti pomocí hlaviček protokolu ETag a HTTP
Každá položka uložená v kontejneru Azure Cosmos DB má systémem definovanou _etag vlastnost. Hodnota _etag je automaticky generována a aktualizována serverem při každé aktualizaci položky. _etag lze použít s hlavičkou požadavku dodanou if-match klientem, aby server mohl rozhodnout, zda lze položku podmíněně aktualizovat. Hodnota hlavičky if-match odpovídá hodnotě _etag na serveru, položka se pak aktualizuje. Pokud už hodnota if-match hlavičky požadavku není aktuální, server operaci odmítne se zprávou odpovědi HTTP 412 Kvůli chybě předběžné podmínky. Klient pak může položku znovu načíst, aby získal aktuální verzi položky na serveru, nebo přepsat verzi položky na serveru vlastní _etag hodnotou položky. Kromě toho je možné použít s hlavičkou if-none-match k určení, _etag jestli je potřeba znovu načíst prostředek.
Hodnota položky se _etag změní při každé aktualizaci položky. Operace nahrazení položky if-match musí být explicitně vyjádřeny jako součást možností žádosti. Příklad najdete v ukázkovém kódu na GitHubu. _etag hodnoty se implicitně kontrolují pro všechny zapsané položky, na které se uložená procedura dotkne. Pokud je zjištěn jakýkoli konflikt, uložená procedura vrátí transakci zpět a vyvolá výjimku. S touto metodou jsou buď všechny zápisy v rámci uložené procedury použity atomicky. Jedná se o signál pro aplikaci, aby znovu aplikala aktualizace a zopakování původního požadavku klienta.
Optimistické řízení souběžnosti a globální distribuce
Souběžné aktualizace položky podléhají OCC vrstvě komunikačního protokolu služby Azure Cosmos DB. U účtů Azure Cosmos DB nakonfigurovaných pro zápisy do jedné oblasti Azure Cosmos DB zajišťuje, aby verze položky, kterou aktualizujete (nebo odstraňujete), na straně klienta byla stejná jako verze položky v kontejneru Azure Cosmos DB. Tím se zajistí, že vaše zápisy budou chráněny před náhodným přepsáním jinými zápisy a naopak. V prostředí s více uživateli vás ovládací prvek optimistické souběžnosti chrání před náhodným odstraněním nebo aktualizací nesprávné verze položky. Položky jsou proto chráněny před nechráněným "ztraceným updatem" nebo "ztraceným odstraněním".
V účtu Služby Azure Cosmos DB s nakonfigurovanými zápisy do více oblastí je možné data potvrdit nezávisle do sekundárních oblastí, pokud se shodují _etag s daty v místní oblasti. Jakmile se nová data potvrdí místně v sekundární oblasti, sloučí se v centru nebo primární oblasti. Pokud zásada řešení konfliktů sloučí nová data do oblasti centra, budou se tato data globálně replikovat s novou _etag. Pokud zásady řešení konfliktů nová data zamítnou, sekundární oblast se vrátí zpět na původní data a _etag.
Další kroky
Další informace o databázových transakcích a řízení optimistické souběžnosti najdete v následujících článcích: