Ří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 je SQL Server, umožňují psát obchodní logiku pomocí uložených procedur a/nebo triggerů, odesílat ji na server pro spuštění přímo v databázovém stroji. U tradičních relačních databází je nutné pracovat se dvěma různými programovacími jazyky programovacího jazyka (neaktorálního) aplikačního jazyka, jako je JavaScript, Python, C#, Java atd. a transakčního programovacího jazyka (například T-SQL), který je nativně spuš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 databázovém stroji hostovaném replikou oddílu. Mezi tyto operace patří zápis (aktualizace jedné nebo více položek v rámci logického oddílu) i operace čtení. Následující tabulka znázorňuje různé operace a typy transakcí:
| Operace | Typ operace | Transakce s jednou nebo více položkami |
|---|---|---|
| Vložení (bez aktivační události před/po) | Write | Transakce s jednou položkou |
| Vložení (s aktivační událostí před/po) | Zápis a čtení | Transakce s více položkami |
| Nahrazení (bez aktivační události před/po) | Write | Transakce s jednou položkou |
| Nahrazení (pomocí aktivační události před/po) | Zápis a čtení | Transakce s více položkami |
| Upsert (bez aktivační události před/po) | Write | Transakce s jednou položkou |
| Upsert (s aktivační událostí před/po) | Zápis a čtení | Transakce s více položkami |
| Odstranění (bez aktivační události před/po) | Write | Transakce s jednou položkou |
| Odstranění (s aktivační událostí před/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 |
| Spuštění procedury sloučení iniciované systémem | Write | Transakce s více položkami |
| Spuštění odstraňování položek iniciované systémem na základě vypršení platnosti (TTL) položky | Write | Transakce s více položkami |
| Přečíst | Přečíst | Transakce s jednou položkou |
| Kanál změn | Čteno | Transakce s více položkami |
| Stránkované čtení | Čteno | Transakce s více položkami |
| Stránkovaný dotaz | Čteno | Transakce s více položkami |
| Spuštění UDF jako součásti stránkovaného dotazu | Čteno | Transakce s více položkami |
Transakce s více položkami
Azure Cosmos DB umožňuje psát uložené procedury, triggery před a po spuštění, uživatelem definované funkce (UDF) a sloučit procedury v JavaScriptu. Azure Cosmos DB nativně podporuje spouštění JavaScriptu v rámci svého databázového stroje. Uložené procedury, triggery před a po spuštění, uživatelem definované funkce (UDF) a procedury sloučení můžete zaregistrovat v kontejneru a později je spustit transakčním procesem v databázovém stroji Azure Cosmos DB. Psaní logiky aplikace v JavaScriptu umožňuje přirozený výraz toku řízení, rozsahu proměnných, přiřazení a integrace primitiv zpracování výjimek v databázových transakcích přímo v jazyce JavaScript.
Uložené procedury, triggery, funkce definované uživatelem a slučovací procedury založené na JavaScriptu jsou zabaleny do okolí transakce ACID s izolací snímků napříč všemi položkami v rámci logického oddílu. Pokud javascriptový program během provádění vyvolá výjimku, celá transakce je přerušena a vrácena zpět. Výsledný programovací model je jednoduchý, ale výkonný. Vývojáři JavaScriptu získají trvalý programovací model, zatímco stále používají známé jazykové konstrukty a primitivy knihoven.
Schopnost spouštět JavaScript přímo v databázovém stroji poskytuje 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, mezi systémy typů aplikace a databází se navíc neshoduje žádná impedance.
Ří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, jeden z nich vyhraje a druhá selže. Pokud se ale jedna nebo dvě operace pokoušející se současně aktualizovat stejnou položku, přečetla starší hodnotu položky, databáze neví, jestli byla dříve přečtená hodnota buď konfliktní operace, nejnovější hodnotou položky. Naštěstí lze tuto situaci zjistit pomocí optimistického řízení souběžnosti (OCC) před tím, než necháte dvě operace vstoupit do hranice transakce uvnitř databázového stroje. OCC chrání vaše data před náhodným přepsáním změn, které provedli jiní uživatelé. Zabrání také tomu, aby ostatní omylem přepsali vaše vlastní změny.
Implementace optimistického řízení souběžnosti pomocí hlaviček ETag a HTTP
Každá položka uložená v kontejneru Azure Cosmos DB má vlastnost definovanou _etag systémem. Hodnota se _etag automaticky vygeneruje a aktualizuje 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, jestli lze položku podmíněně aktualizovat. Hodnota hlavičky if-match odpovídá hodnotě _etag na serveru, položka se pak aktualizuje. Pokud hodnota if-match hlavičky požadavku již není aktuální, server odmítne operaci se zprávou http 412 o selhání předběžné podmínky. Klient pak může položku znovu načíst, aby získala 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 _etag se změní při každé aktualizaci položky. Pro operace if-match nahrazení položky musí být explicitně vyjádřen jako součást možností žádosti. Příklad najdete v ukázkovém kódu na GitHubu. _etag hodnoty jsou implicitně kontrolovány pro všechny zapsané položky ovlivněné uloženou procedurou. Pokud se zjistí nějaký konflikt, uložená procedura vrátí transakce zpět a vyvolá výjimku. Při použití této metody se všechny nebo žádné zápisy v rámci uložené procedury použijí atomicky. Toto je signál aplikace k opětovnému použití aktualizací a opakování původní žádosti klienta.
Optimistická řízení souběžnosti a globální distribuce
Souběžné aktualizace položky podléhají protokolu OCC vrstvě komunikačního protokolu služby Azure Cosmos DB. Pro účty Azure Cosmos DB nakonfigurované pro zápisy do jedné oblasti zajišťuje Azure Cosmos DB, aby verze položky, kterou aktualizujete (nebo odstraňujete), byla stejná jako verze položky v kontejneru Azure Cosmos DB. Tím zajistíte, že vaše zápisy budou chráněny před náhodným přepsáním zápisy ostatních a naopak. V prostředí s více uživateli chrání ovládací prvek optimistické souběžnosti před náhodným odstraněním nebo aktualizací nesprávné verze položky. V takovém případě jsou položky chráněny před neznámými problémy se ztrátou aktualizace nebo ztráty odstranění.
V účtu služby Azure Cosmos DB nakonfigurovaného pro zápisy do více oblastí je možné data potvrdit nezávisle do sekundárních oblastí, pokud se shoduje _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ásady řešení konfliktů sloučí nová data do oblasti centra, budou se tato data replikovat globálně s novým _etag. Pokud zásada řešení konfliktů odmítne nová data, sekundární oblast se vrátí zpět k původním datům a _etag.
Další kroky
Další informace o databázových transakcích a optimistické kontrole souběžnosti najdete v následujících článcích: