Tranzakciók és optimista egyidejűség vezérlése
A KÖVETKEZŐRE VONATKOZIK: 
NoSQL
Az adatbázis-tranzakciók biztonságos és kiszámítható programozási modellt biztosítanak az adatok egyidejű változásainak kezeléséhez. A hagyományos relációs adatbázisok, például a SQL Server lehetővé teszik az üzleti logika írását tárolt eljárások és/vagy triggerek használatával, és közvetlenül az adatbázismotoron belül küldik el a kiszolgálónak végrehajtás céljából. A hagyományos relációs adatbázisok esetében két különböző programozási nyelvvel kell foglalkoznia a (nem tranzakciós) alkalmazásprogramozási nyelvekkel, például a JavaScript, a Python, a C#, a Java stb. és az adatbázis által natív módon végrehajtott tranzakciós programozási nyelv (például T-SQL).
Az Azure Cosmos DB adatbázismotorja a pillanatkép-elkülönítéssel támogatja a teljes ACID-kompatibilis tranzakciókat (Atomitás, Konzisztencia, Elkülönítés, Tartósság). A tároló logikai partícióinak hatókörébe tartozó összes adatbázis-művelet tranzakciós módon lesz végrehajtva a partíció replikája által üzemeltetett adatbázismotoron belül. Ezek a műveletek írási (egy vagy több elem logikai partíción belüli frissítése) és olvasási műveleteket is tartalmaznak. Az alábbi táblázat különböző műveleteket és tranzakciótípusokat mutat be:
| Művelet | Művelet típusa | Egy- vagy többelemes tranzakció |
|---|---|---|
| Beszúrás (előzetes/utólagos eseményindító nélkül) | Írás | Egyelemes tranzakció |
| Beszúrás (előre/post eseményindítóval) | Írás és olvasás | Többelemes tranzakció |
| Csere (előzetes/utólagos eseményindító nélkül) | Írás | Egyelemes tranzakció |
| Csere (előre/utólagos eseményindítóval) | Írás és olvasás | Többelemes tranzakció |
| Upsert (előzetes/utólagos eseményindító nélkül) | Írás | Egyelemes tranzakció |
| Upsert (előzetes/utólagos eseményindítóval) | Írás és olvasás | Többelemes tranzakció |
| Törlés (előzetes/utólagos eseményindító nélkül) | Írás | Egyelemes tranzakció |
| Törlés (előre/post eseményindítóval) | Írás és olvasás | Többelemes tranzakció |
| Tárolt eljárás végrehajtása | Írás és olvasás | Többelemes tranzakció |
| Egyesítési eljárás rendszer által kezdeményezett végrehajtása | Írás | Többelemes tranzakció |
| Rendszer által kezdeményezett elemek törlése egy elem lejárata (TTL) alapján | Írás | Többelemes tranzakció |
| Olvasás | Olvasás | Egyelemes tranzakció |
| Változáscsatorna | Olvasás | Többelemes tranzakció |
| Lapszámozott olvasás | Olvasás | Többelemes tranzakció |
| Lapszámozott lekérdezés | Olvasás | Többelemes tranzakció |
| UDF végrehajtása a lapszámozott lekérdezés részeként | Olvasás | Többelemes tranzakció |
Többelemes tranzakciók
Az Azure Cosmos DB lehetővé teszi tárolt eljárások, előzetes/utólagos triggerek, felhasználó által definiált függvények (UDF-ek) írását és egyesítési eljárásokat a JavaScriptben. Az Azure Cosmos DB natív módon támogatja a JavaScript-végrehajtást az adatbázismotorban. Regisztrálhat tárolt eljárásokat, előzetes/utólagos eseményindítókat, felhasználó által definiált függvényeket (UDF-eket) és egyesítheti az eljárásokat egy tárolón, majd később tranzakciós módon végrehajthatja őket az Azure Cosmos DB adatbázismotorján belül. Az alkalmazáslogika JavaScriptben való írása lehetővé teszi a vezérlőfolyamat természetes kifejezését, a változók hatókörkezelését, a hozzárendelést és a kivételkezelés primitívjeinek integrálását az adatbázis-tranzakciókban közvetlenül a JavaScript nyelven.
A JavaScript-alapú tárolt eljárások, eseményindítók, UDF-ek és egyesítési eljárások egy környezeti ACID-tranzakcióba vannak csomagolva, pillanatkép-elkülönítéssel a logikai partíció összes elemében. A végrehajtás során, ha a JavaScript-program kivételt jelez, a rendszer megszakítja és visszaállítja a teljes tranzakciót. Az eredményként kapott programozási modell egyszerű, mégis hatékony. A JavaScript-fejlesztők tartós programozási modellt kapnak, miközben a megszokott nyelvi szerkezeteket és kódtári primitíveket használják.
A JavaScript közvetlenül az adatbázismotoron belüli végrehajtásának képessége biztosítja az adatbázis-műveletek teljesítményét és tranzakciós végrehajtását egy tároló elemein. Emellett mivel az Azure Cosmos DB adatbázismotor natív módon támogatja a JSON-t és a JavaScriptet, nincs eltérés az alkalmazás típusrendszerei és az adatbázis között.
Optimista egyidejűség-vezérlés
Az optimista egyidejűség-vezérlés lehetővé teszi az elveszett frissítések és törlések megelőzését. Egyidejűleg az ütköző műveletek az elemet birtokoló logikai partíció által üzemeltetett adatbázismotor rendszeres pesszimista zárolásának vannak kitéve. Amikor két egyidejű művelet megkísérli frissíteni egy elem legújabb verzióját egy logikai partíción belül, az egyik nyer, a másik pedig sikertelen lesz. Ha azonban egy vagy két művelet, amely ugyanannak az elemnek az egyidejű frissítését kísérli meg, korábban már beolvasta az elem egy régebbi értékét, az adatbázis nem tudja, hogy a korábban vagy mindkét ütköző művelet által beolvasott érték valóban az elem legújabb értéke volt-e. Szerencsére ez a helyzet az optimista egyidejűség-vezérléssel (OCC) észlelhető, mielőtt a két művelet belépteti a tranzakció határát az adatbázismotoron belül. Az OCC megvédi az adatokat attól, hogy véletlenül felülírják a mások által végrehajtott módosításokat. Azt is megakadályozza, hogy mások véletlenül felülírják a saját módosításait.
Optimista egyidejűség-vezérlés megvalósítása ETag- és HTTP-fejlécek használatával
Minden Azure Cosmos DB-tárolóban tárolt elem rendelkezik egy rendszer által definiált _etag tulajdonságokkal. A kiszolgáló minden alkalommal automatikusan létrehozza és frissíti az érték értékét _etag , amikor az elem frissül. _etag az ügyfél által megadott if-match kérelemfejléc használatával a kiszolgáló eldöntheti, hogy egy elem feltételesen frissíthető-e. A fejléc értéke if-match megegyezik a kiszolgálón lévő értékével _etag , az elem ezután frissül. Ha a if-match kérelemfejléc értéke már nem aktuális, a kiszolgáló a "HTTP 412 előfeltételhiba" válaszüzenettel utasítja el a műveletet. Az ügyfél ezután újra lekérheti az elemet az elem aktuális verziójának beszerzéséhez a kiszolgálón, vagy felülbírálhatja a kiszolgálón lévő elem verzióját az elem saját _etag értékével. Emellett a if-none-match fejlécmel is meghatározható, _etag hogy szükség van-e egy erőforrás újrabetöltésére.
Az elem _etag értéke minden alkalommal megváltozik, amikor az elem frissül. A csereelem-műveletek if-match esetében explicit módon kell kifejezni a kérési beállítások részeként. Példaként tekintse meg a GitHub mintakódját. _etag a rendszer implicit módon ellenőrzi a tárolt eljárás által érintett összes írott elemet. Ütközés észlelése esetén a tárolt eljárás visszaállítja a tranzakciót, és kivételt okoz. Ezzel a módszerrel a tárolt eljárásban lévő összes vagy egyetlen írás sem alkalmazható atomi módon. Ez jelzi az alkalmazásnak, hogy újra alkalmazza a frissítéseket, és próbálkozzon újra az eredeti ügyfélkéréssel.
Optimista egyidejűség-vezérlés és globális elosztás
Az elemek egyidejű frissítéseit az Azure Cosmos DB kommunikációs protokollrétege az OCC-nek veti alá. Az egyrégiós írásokhoz konfigurált Azure Cosmos DB-fiókok esetében az Azure Cosmos DB biztosítja, hogy a frissíteni kívánt elem ügyféloldali verziója (vagy törlése) megegyezik az Azure Cosmos DB-tárolóban található elem verziójával. Ez biztosítja, hogy az írások ne legyenek véletlenül felülírva mások írásai által, és fordítva. Többfelhasználós környezetben az optimista egyidejűség-vezérlés megvédi Önt attól, hogy véletlenül töröljön vagy frissítsen egy elem helytelen verzióját. Így az elemek védettek lesznek a hírhedt "elveszett frissítés" vagy "elveszett törlés" problémák ellen.
A többrégiós írásokkal konfigurált Azure Cosmos DB-fiókokban az adatok egymástól függetlenül, másodlagos régiókba is véglegeshetők, ha azok _etag megegyeznek a helyi régióban lévő adatokkal. Ha az új adatok helyileg lesznek véglegesítve egy másodlagos régióban, azokat a központi vagy elsődleges régióban egyesítjük. Ha az ütközésfeloldási szabályzat egyesíti az új adatokat a központi régióban, akkor ezeket az adatokat globálisan replikálja a rendszer az újkal _etag. Ha az ütközésfeloldási szabályzat elutasítja az új adatokat, a másodlagos régió vissza lesz állítva az eredeti adatokra, és _etaga .
Következő lépések
További információ az adatbázis-tranzakciókról és az optimista egyidejűség-vezérlésről az alábbi cikkekben: