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 az SQL Server lehetővé teszik az üzleti logika írását tárolt eljárások és/vagy eseményindítók használatával, és közvetlenül az adatbázismotoron belüli végrehajtás céljából küldhetők el a kiszolgálóra. 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 JavaScripttel, a Pythonnal, a C#-tal, a Java-val stb. és az adatbázis által natívan végrehajtott tranzakciós programozási nyelvvel (például T-SQL).
Az Azure Cosmos DB adatbázismotorja támogatja a teljes ACID-kompatibilis tranzakciókat (atomiság, konzisztencia, elkülönítés, tartósság) pillanatkép-elkülönítéssel. A tároló logikai partíciójának hatókörén belüli összes adatbázisművelet tranzakciósan 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űvelettípus | Egy- vagy többelemes tranzakció |
|---|---|---|
| Beszúrás (elő-/utáni eseményindító nélkül) | Írás | Egyelemes tranzakció |
| Beszúrás (elő-/utáni 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ő-/utáni eseményindítóval) | Írás és olvasás | Többelemes tranzakció |
| Upsert (előzetes/post trigger nélkül) | Írás | Egyelemes tranzakció |
| Upsert (előzetes/post triggerrel) | Írás és olvasás | Többelemes tranzakció |
| Törlés (előzetes/közzétételi eseményindító nélkül) | Írás | Egyelemes tranzakció |
| Törlés (előzetes/közzétételi 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ó |
| Az elemek törlésének rendszer által kezdeményezett végrehajtása egy elem lejárata (TTL) alapján | Írás | Többelemes tranzakció |
| Olvasás | Olvasás | Egytételes 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 a tárolt eljárások, a pre/post triggerek, a felhasználó által definiált függvények (UDF-ek) írását és az eljárások egyesítését JavaScriptben. Az Azure Cosmos DB natív módon támogatja a JavaScript-végrehajtást az adatbázismotoron belül. Regisztrálhatja a tárolt eljárásokat, az elő-/post triggereket, a 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ázismotoron 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örét, a hozzárendelést és a kivételkezelési primitívek 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 teljes tranzakció megszakad és visszagördül. 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ár-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. Továbbá, 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. Az egyidejű, ütköző műveleteket az elem tulajdonosának logikai partíciója által üzemeltetett adatbázismotor rendszeres pesszimista zárolása okozza. Ha 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 ugyanazon elem egyidejű frissítését kísérli meg, korábban 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éphet a tranzakció határára 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
Az Azure Cosmos DB-tárolóban tárolt minden elem rendelkezik rendszer által meghatározott _etag tulajdonságokkal. A kiszolgáló minden alkalommal automatikusan létrehozza és frissíti az értékeket _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érés fejlécének értéke már nem aktuális, a kiszolgáló elutasítja a műveletet egy "HTTP 412 előfeltételi hiba" válaszüzenettel. Az ügyfél ezután újra lekérheti az elemet az elem aktuális verziójának lekéré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écben is meghatározhatja, _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 elem értékét. Ü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 rendszer a tárolt eljáráson belüli összes vagy egyetlen írást sem alkalmazza atomilag. Ez jelzi az alkalmazásnak, hogy újra alkalmazza a frissítéseket, és újrapróbálkozza az eredeti ügyfélkérést.
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 (vagy törölni) kívánt elem ügyféloldali verziója megegyezik az Azure Cosmos DB-tárolóban található elem verziójával. Ez biztosítja, hogy az írásait ne írja felül véletlenül mások írása, é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.
Többrégiós írással konfigurált Azure Cosmos DB-fiókban az adatok egymástól függetlenül leküldhetők másodlagos régiókba, 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özpont vagy az elsődleges régió egyesíti. Ha az ütközésfeloldási szabályzat egyesíti az új adatokat a központi régióban, akkor az adatok globálisan replikálódnak 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: