Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
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 triggerek használatával, majd közvetlenül az adatbázismotoron belüli végrehajtás céljából elküldheti a kiszolgálónak.
A hagyományos relációs adatbázisok esetében két különböző programozási nyelvet kell kezelnie: egy nem tranzakciós alkalmazásprogramozási nyelvet, például JavaScriptet, Pythont, C#-t vagy Java-t; és egy tranzakciós programozási nyelvet, például a T-SQL-t, amelyet az adatbázis natív módon hajt végre.
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 sorol fel:
| Művelet | Művelet típusa | 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őtti/utáni trigger nélkül) | Írás | Egyelemes tranzakció |
| Upsert (előtti/utáni triggerrel) | Í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őtti/utáni 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ásértesítés | Olvasás | Többelemes tranzakció |
| Lapozott olvasás | Olvasás | Többelemes tranzakció |
| Paginált lekérdezés | Olvasás | Többelemes tranzakció |
| UDF végrehajtása a lapozott 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, eseményindítók és felhasználó által definiált függvények írását, valamint 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őzetes/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 (OCC) lehetővé teszi az elveszett frissítések és törlések megelőzését. Az egyidejű, ütköző műveletek az elem tulajdonosának logikai partíciója által üzemeltetett adatbázismotor szokásos pesszimista zárolásának vannak alávetve. 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 sikertelen. Ha azonban egy vagy két művelet, amely ugyanazon elem egyidejű frissítését kísérli meg, korábban az elem egy régebbi értékét olvasta, 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 OCC-vel é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.
ETag-ek és HTTP-fejlécek használatával optimista párhuzamosság-vezérlés megvalósítása
Az Azure Cosmos DB-tárolóban tárolt minden elem rendelkezik rendszer által meghatározott _etag tulajdonságokkal. A _etag értékét a kiszolgáló automatikusan létrehozza és frissíti minden alkalommal, amikor az elemet frissítik.
_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. Ha a if-match fejléc értéke megegyezik a kiszolgálón lévő értékével _etag , akkor az elem 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, hogy megszerezze a kiszolgálón tárolt elem aktuális verzióját, vagy felülírhatja az elem verzióját a saját _etag értékével a kiszolgálón. Továbbá a _etag használható a if-none-match fejléccel annak meghatározására, 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 csere műveleteknél a if-match-t explicit módon kell kifejezni, mint a kérési beállítások egyik elemét. Példaként tekintse meg a GitHub mintakódját. A _etag rendszer implicit módon ellenőrzi az értékeket a tárolt eljárás által érintett összes írott elem esetében. Ü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áson belüli írások mindegyike vagy egyike sem kerül alkalmazásra atomikusan. 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 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á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ítse az elem nem megfelelő 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özponti vagy az elsődleges régióban egyesítik. 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 _etag.
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: