A hírcsatorna tervezési mintáinak módosítása az Azure Cosmos DB-ben

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az Azure Cosmos DB változáscsatorna lehetővé teszi a nagy mennyiségű írással rendelkező nagy adathalmazok hatékony feldolgozását. A változáscsatorna alternatívát is kínál a teljes adatkészlet lekérdezésére a megváltozott adatok azonosításához. Ez a cikk a változáscsatorna tervezési mintáival, a tervezési kompromisszumokkal és a változáscsatorna korlátozásával foglalkozik.

Az Azure Cosmos DB jól használható IoT-, játék-, kiskereskedelmi és üzemeltetési naplózási alkalmazásokhoz. Ezekben az alkalmazásokban gyakori tervezési minta az adatok módosításainak használata más műveletek indításához. Ilyen műveletek például a következők:

• Értesítés vagy API-hívás indítása egy elem beszúrása, frissítése vagy törlésekor.
• Valós idejű streamfeldolgozás IoT-hez vagy valós idejű elemzési feldolgozáshoz működési adatokon.
• Adatáthelyezés, például szinkronizálás gyorsítótárral, keresőmotorral, adattárházzal vagy hűtőtárolóval.

Az Azure Cosmos DB változáscsatornája lehetővé teszi, hogy hatékony és méretezhető megoldásokat hozzon létre az egyes mintákhoz, ahogyan az alábbi képen látható:

Esemény-számítástechnika és értesítések

Az Azure Cosmos DB változáscsatornája leegyszerűsítheti azokat a forgatókönyveket, amelyeknek egy értesítés indítására vagy egy api-nak való hívásra van szükségük egy adott esemény alapján. A változáscsatorna-feldolgozóval automatikusan lekérdezheti a tárolót a módosításokért, majd meghívhat egy külső API-t minden egyes írási, frissítési vagy törlési műveletnél.

Az értesítéseket szelektíven is aktiválhatja, vagy adott feltételek alapján hívást küldhet egy API-nak. Ha például az Azure Functions használatával olvas a változáscsatornából, logikát helyezhet a függvénybe, hogy csak egy feltétel teljesülése esetén küldjön értesítést. Bár az Azure-függvénykód minden módosításhoz végrehajtható, az értesítést csak akkor küldi el a rendszer, ha a feltétel teljesül.

Valós idejű adatfolyam-feldolgozás

Az Azure Cosmos DB változáscsatorna használható valós idejű streamfeldolgozáshoz IoT- vagy valós idejű elemzési műveletekhez a működési adatokon. Előfordulhat például, hogy események adatait fogadja és tárolja az eszközöktől, érzékelőktől, infrastruktúrától és alkalmazásoktól, majd valós időben feldolgozhatja ezeket az eseményeket a Spark használatával. Az alábbi ábra bemutatja, hogyan valósíthat meg lambda architektúrát az Azure Cosmos DB változáscsatorna használatával:

A streamfeldolgozási implementációk sok esetben először nagy mennyiségű bejövő adatot kapnak egy ideiglenes üzenetsorba, például az Azure Event Hubsba vagy az Apache Kafkába. A változáscsatorna nagyszerű alternatíva, mivel az Azure Cosmos DB képes tartósan magas adatbetöltést támogatni, garantáltan alacsony olvasási és írási késéssel. Az Azure Cosmos DB változáscsatornájának előnyei az üzenetsorokkal szemben a következők:

Adatmegőrzés

Az Azure Cosmos DB-be írt adatok megjelennek a változáscsatornában. Az adatok mindaddig megmaradnak a változáscsatornában, amíg el nem törlődnek, ha a legújabb verziómóddal olvas. Az üzenetsorok általában maximális megőrzési idővel rendelkeznek. Az Azure Event Hubs például 90 napos maximális adatmegőrzést biztosít.

Lekérdezési képesség

Az Azure Cosmos DB-tároló változáscsatornájából való olvasás mellett SQL-lekérdezéseket is futtathat az Azure Cosmos DB-ben tárolt adatokon. A változáscsatorna nem a tárolóban lévő adatok duplikálása, hanem az adatok olvasásának egy másik mechanizmusa. Ezért ha adatokat olvas a változáscsatornából, az adatok mindig összhangban állnak ugyanahhoz az Azure Cosmos DB-tárolóhoz tartozó lekérdezésekkel.

Magas szintű rendelkezésre állás

Az Azure Cosmos DB akár 99,999%-os olvasási és írási rendelkezésre állást is kínál. A sok üzenetsortól eltérően az Azure Cosmos DB-adatok globálisan egyszerűen terjeszthetők és konfigurálhatók nulla helyreállítási időkorláttal (RTO ).

Miután feldolgozta a változáscsatorna elemeit, létrehozhat egy materializált nézetet, és megőrizheti az összesített értékeket az Azure Cosmos DB-ben. Ha például az Azure Cosmos DB-t használja egy játék létrehozásához, a változáscsatorna használatával valós idejű ranglistákat valósíthat meg a befejezett játékok pontszámai alapján.

Adatáthelyezés

A változáscsatornából a valós idejű adatáthelyezéshez is olvashat.

A változáscsatorna segítségével például hatékonyan végezheti el a következő feladatokat:

• Gyorsítótár, keresési index vagy adattárház frissítése az Azure Cosmos DB-ben tárolt adatokkal.

• Nulla állásidős migrálás végrehajtása egy másik Azure Cosmos DB-fiókba vagy egy másik, más logikai partíciókulcsot tartalmazó Azure Cosmos DB-tárolóba.

• Alkalmazásszintű adatrétegezés és -archiválás implementálása. Tárolhat például "gyakori adatokat" az Azure Cosmos DB-ben, és "hideg adatokat" öregítheti más tárolórendszerekbe, például az Azure Blob Storage-ba.

Ha partíciók és tárolók között kell denormalizálnia az adatokat, az adatreplikálás forrásaként a tároló változáscsatornájából olvashat. A változáscsatorna valós idejű adatreplikálása csak a végleges konzisztenciát garantálja. Megfigyelheti , hogy a változáscsatorna-feldolgozó mennyivel marad el az Azure Cosmos DB-tároló változásainak feldolgozása során.

Event Sourcing

Az esemény-beszerzési minta magában foglalja egy csak hozzáfűző tároló használatát az adatokon végzett műveletek teljes sorozatának rögzítéséhez. Az Azure Cosmos DB változáscsatornája nagyszerű választás központi adattárként olyan eseményoldali forrásarchitektúrákban, amelyekben az összes adatbetöltés írásként van modellezve (frissítések és törlések nélkül). Ebben az esetben minden írás az Azure Cosmos DB-be egy "esemény", így a változáscsatorna a korábbi események teljes rekordját tárolja. A központi eseménytár által közzétett események jellemző felhasználási módja a materializált nézetek fenntartása vagy a külső rendszerekkel való integráció. Mivel a változáscsatorna legújabb verziómódjában nincs időkorlát a megőrzésre, az Azure Cosmos DB-tároló változáscsatornájának kezdetétől kezdve újra lejátszhatja az összes múltbeli eseményt. Akár több változáscsatorna-felhasználó is előfizethet ugyanahhoz a tárolóhoz tartozó változáscsatornára.

Az Azure Cosmos DB egy nagy, csak hozzáfűző állandó adattár az esemény beszerzési mintájában, mert a horizontális méretezhetőség és a magas rendelkezésre állás erősségei miatt. Emellett a változáscsatorna-feldolgozó "legalább egyszer" garanciát is kínál, biztosítva, hogy ne hagyja ki az események feldolgozását.

Jelenlegi korlátozások

A változáscsatorna több móddal rendelkezik, amelyek mindegyike fontos korlátozásokkal rendelkezik, amelyeket érdemes megismernie. Több területet is figyelembe kell venni, ha olyan alkalmazást tervez, amely a változáscsatornát a legújabb verzió módban vagy az összes verzióban és törlési módban használja.

Köztes frissítések

Legújabb verziómód

A legújabb verzió módban csak az adott elem legutóbbi módosítása szerepel a változáscsatornában. A módosítások feldolgozásakor a legújabb elérhető elemverziót olvassa el. Ha egy elemhez rövid idő alatt több frissítés is tartozik, előfordulhat, hogy nem dolgoz fel köztes frissítéseket. Ha egy elem korábbi frissítéseit szeretné visszajátszani, ezeket a frissítéseket írási sorozatként modellezheti, vagy használhatja az összes verziót és törlési módot.

Minden verzió és törlési mód (előzetes verzió)

Minden verzió és törlési mód az összes művelet összes elemverziójának teljes műveleti naplóját biztosítja. A rendszer nem hagyja ki a köztes frissítéseket, ha azok a fiókhoz konfigurált folyamatos biztonsági mentési megőrzési időszakon belül történtek.

Törlések

Legújabb verziómód

A változáscsatorna legújabb verziómódja nem rögzíti a törléseket. Ha töröl egy elemet a tárolóból, az is törlődik a változáscsatornából. A törlések kezelésének leggyakoribb módja egy helyreállítható jelölő hozzáadása a törölt elemekhez. Hozzáadhat egy hívott deleted tulajdonságot, és beállíthatja a true törlés időpontjában. Ez a dokumentumfrissítés megjelenik a változáscsatornában. Beállíthat egy élettartamot (TTL) ezen az elemen, hogy később automatikusan törölhető legyen.

Minden verzió és törlési mód (előzetes verzió)

A törlések minden verzióban rögzítve vannak, és törlési módban is rögzítve vannak, anélkül, hogy egy helyreállítható törlési jelölőt kellene beállítaniuk. Olyan metaadatokat is kap, amelyek jelzik, hogy a törlés TTL-lejáratból történt-e.

Megőrzés

Legújabb verziómód

A változáscsatorna a legújabb verzió módban korlátlan megőrzéssel rendelkezik. Ha egy elem létezik a tárolóban, az elérhető a változáscsatornában.

Minden verzió és törlési mód (előzetes verzió)

Az összes verzió és törlési mód lehetővé teszi, hogy csak a fiókhoz konfigurált folyamatos biztonsági mentési megőrzési időszakon belül történt módosításokat olvassa be. Ha a fiókja hét napos megőrzési időtartammal van konfigurálva, nem olvashatja el a nyolc nappal ezelőtti módosításokat. Ha az alkalmazásnak a tároló elejétől kell nyomon követnie az összes frissítést, a legújabb verziómód jobb választás lehet.

Garantált rendelés

Minden változáscsatorna-módnak garantált sorrendje van egy partíciókulcs-értéken belül, de a partíciókulcs értékei között nem. Olyan partíciókulcsot kell választania, amely garantálja a megfelelő sorrendet.

Vegyük például egy olyan kiskereskedelmi alkalmazást, amely az esemény-beszerzési tervezési mintát használja. Ebben az alkalmazásban a különböző felhasználói műveletek mindegyike "esemény", amely az Azure Cosmos DB-be való írásként van modellezve. Képzelje el, hogy a következő sorrendben történt-e példaesemény:

1. Az ügyfél hozzáadja az A elemet a bevásárlókocsihoz.
2. Az ügyfél hozzáadja a "B" elemet a bevásárlókocsihoz.
3. Az ügyfél eltávolítja az A elemet a bevásárlókocsiból.
4. Az ügyfél kijelentkezik, és a kosár tartalmát kiszállítjuk.

Az aktuális bevásárlókocsi tartalmának materializált nézete minden ügyfél számára megmarad. Az alkalmazásnak gondoskodnia kell arról, hogy ezek az események a folyamatuk sorrendjében legyenek feldolgozva. Ha például a kosár kivételét az A elem eltávolítása előtt kellett volna feldolgozni, akkor valószínű, hogy az A tételt szállították volna az ügyfélnek, és nem azt a tételt, amelyet az ügyfél inkább a B tételre szeretett volna. Annak érdekében, hogy ez a négy esemény az előfordulásuk sorrendjében legyen feldolgozva, ugyanabban a partíciókulcs-értékben kell lennie. Ha a partíciókulcsot választja username (minden ügyfél egyedi felhasználónévvel rendelkezik), garantálhatja, hogy ezek az események ugyanabban a sorrendben jelenjenek meg a változáscsatornában, amelyben az Azure Cosmos DB-be vannak írva.

Példák

Íme néhány valós változáscsatornakód a legújabb verziómódra, amely túlmutat a megadott minták hatókörén:

• A változáscsatorna bemutatása
• Az IoT-használati eset középpontjában a változáscsatorna áll
• Kiskereskedelmi használati eset középpontjában a változáscsatorna áll

Következő lépések

• Tekintse át a változáscsatorna áttekintését.
• További információ a változáscsatorna-módokról.
• Megtudhatja, hogy hogyan olvashatja el a változáscsatornát.
• Kapacitástervezést szeretne végezni az Azure Cosmos DB-be való migráláshoz? A kapacitástervezéshez használhatja a meglévő adatbázisfürt adatait.
  • Ha csak a meglévő adatbázisfürt virtuális magjainak és kiszolgálóinak számát ismeri, olvassa el a kérelemegységek becslését virtuális magok vagy vCPU-k használatával.
  • Ha ismeri az aktuális adatbázis számítási feladataira vonatkozó tipikus kérési arányokat, olvassa el a kérelemegységek becslését az Azure Cosmos DB kapacitástervező használatával.