Share via

Adatplatformokkal kapcsolatos szempontok az Azure-ban kritikus fontosságú számítási feladatokhoz

  • Cikk

A hatékony alkalmazás-adatplatform kiválasztása egy további kulcsfontosságú döntési terület, amely messzemenő következményekkel jár a többi tervezési területen. Az Azure végső soron számos relációs, nem relációs és elemzési adatplatformot kínál, amelyek képességei nagyban különböznek egymástól. Ezért elengedhetetlen, hogy a kulcsfontosságú nem funkcionális követelmények teljes mértékben figyelembe legyenek véve más döntési tényezőkkel együtt, mint például a konzisztencia, az működőképesség, a költség és az összetettség. A többrégiós írási konfigurációban való működés például kritikus hatással lesz a globálisan elérhető platform alkalmasságára.

Ez a tervezési terület kibővül az alkalmazástervezéssel, és fontos szempontokat és javaslatokat nyújt az optimális adatplatform kiválasztásának tájékoztatásához.

Fontos

Ez a cikk az Azure Well-Architected kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a kritikus fontosságú számítási feladatokkal?

A négy vs big data

A "Four Vs of Big Data" keretrendszerrel jobban megérthetők a magas rendelkezésre állású adatplatformok szükséges jellemzői, és hogy az adatok hogyan használhatók fel az üzleti érték maximalizálására. Ebből a szakaszból megtudhatja, hogyan alkalmazhatók a Kötet, a Sebesség, a Változatosság és a Veracity jellemzői fogalmi szinten, hogy a megfelelő adattechnológiák használatával tervezhessenek adatplatformokat.

  • Volume: mennyi adat érkezik be a tárolási kapacitás és a rétegzési követelmények tájékoztatásához – ez az adathalmaz mérete.
  • Velocity : az adatok feldolgozásának sebessége kötegként vagy folyamatos adatfolyamként – ez a folyamat sebessége.
  • Variety: az adatok rendszerezése és formátuma, strukturált, részben strukturált és strukturálatlan formátumok rögzítése – azaz több üzlet vagy típus adatai.
  • V-törlés: magában foglalja a vállalatirányítás és az adatminőség-biztosítás szempontjából figyelembe vett adatkészletek eredetét és kiválogatását , azaz az adatok pontosságát.

Kialakítási szempontok

Kötet

  • Meglévő (ha vannak ilyenek) és várható jövőbeli adatmennyiségek az üzleti célkitűzésekhez és tervekhez igazodó előrejelzett adatnövekedési arányok alapján.

    • Az adatmennyiségnek magában kell foglalnia magát az adatokat, valamint az indexeket, naplókat, telemetriát és más alkalmazható adatkészleteket.
    • A nagy üzleti szempontból kritikus és kritikus fontosságú alkalmazások általában napi rendszerességgel hoznak létre és tárolnak nagy mennyiségű (GB és TB) kapacitást.
    • Az adatbővítés jelentős költségekkel járhat.

  • Az adatmennyiség ingadozhat a változó üzleti körülmények vagy a takarítási eljárások miatt.

  • Az adatmennyiség jelentős hatással lehet az adatplatform lekérdezési teljesítményére.

  • Az adatplatform kötetkorlátainak elérése jelentős hatással lehet.

    • Állásidőt eredményez? és ha igen, mennyi ideig?
    • Mik a kockázatcsökkentési eljárások? és a kockázatcsökkentés alkalmazásmódosítást igényel?
    • Fennáll az adatvesztés kockázata?

  • Az olyan funkciók, mint az élettartam (TTL) az adatnövekedés kezelésére használhatók úgy, hogy az eltelt idő után automatikusan törlik a rekordokat a rekordok létrehozásával vagy módosításával.

Sebesség

  • A különböző alkalmazás-összetevőkből származó adatok kibocsátásának sebessége, valamint az adatok véglegesítésének és lekérésének sebességére vonatkozó követelmények kritikus fontosságúak az optimális adattechnológia meghatározásához a kulcsfontosságú számítási feladatok forgatókönyveihez.

    • Az átviteli sebességre vonatkozó követelmények természete a számítási feladatok forgatókönyve szerint változik, például az írási és írási terhelés esetén.
      • Az elemzési számítási feladatoknak például általában nagy olvasási átviteli sebességet kell kiszolgálnia.
    • Mi a szükséges átviteli sebesség? És hogyan fog növekedni az átviteli sebesség?
    • Milyen adatkésési követelmények vonatkoznak a P50/P99-re a referenciaterhelési szinteken?

  • Az olyan képességek, mint a zárolásmentes kialakítás támogatása, az indexhangolás és a konzisztenciaszabályzatok kritikus fontosságúak a magas átviteli sebesség eléréséhez.

    • A magas átviteli sebesség konfigurációjának optimalizálása kompromisszumot von maga után, amelyet teljes mértékben meg kell érteni.
    • A terhelésszintű adatmegőrzési és üzenetkezelési minták, például a CQRS és az Event Sourcing az átviteli sebesség további optimalizálására használhatók.

  • A terhelési szintek természetesen ingadoznak számos alkalmazásforgatókönyv esetében, mivel a természetes csúcsok megfelelő fokú rugalmasságot igényelnek a változó igények kezeléséhez, miközben fenntartják az átviteli sebességet és a késést.

    • Az agilis skálázhatóság kulcsfontosságú a változó átviteli sebesség és a terhelési szintek hatékony támogatásához anélkül, hogy túlterheli a kapacitásszinteket.
      • Az olvasási és írási átviteli sebességnek az alkalmazás követelményeinek és a terhelésnek megfelelően kell méreteznie.
      • Függőleges és vízszintes méretezési műveletek is alkalmazhatók a változó terhelési szintekre való reagáláshoz.

  • Az átviteli sebesség visszaesésének hatása a számítási feladatok forgatókönyvétől függően változhat.

    • Megszakad a kapcsolat?
    • Az egyes műveletek hibakódokat adnak vissza, amíg a vezérlősík továbbra is működik?
    • Aktiválja az adatplatform a szabályozást, és ha igen, mennyi ideig?

  • Az aktív-aktív földrajzi elosztás használatára vonatkozó alapvető alkalmazástervezési javaslat kihívást jelent az adatkonzisztenciával.

    • A konzisztencia és a teljesítmény közötti kompromisszum a teljes ACID tranzakciós szemantika és a hagyományos zárolási viselkedés tekintetében.
      • Az írási késés minimalizálása az adatkonzisztenciával jár.

  • Többrégiós írási konfiguráció esetén a módosításokat szinkronizálni és egyesíteni kell az összes replika között, szükség esetén ütközésfeloldással, ami hatással lehet a teljesítményszintekre és a méretezhetőségre.

  • Az írásvédett replikák (régiókon belüli és régiók közötti) használatával minimalizálható a lekerekítési késés és a forgalom elosztása a teljesítmény, az átviteli sebesség, a rendelkezésre állás és a méretezhetőség növelése érdekében.

  • A gyorsítótárazási réteggel növelhető az olvasási sebesség a felhasználói élmény és a végpontok közötti ügyfél válaszidejének javítása érdekében.

    • A gyorsítótár lejárati idejét és szabályzatát figyelembe kell venni az adatok frissességének optimalizálásához.

Különböző

  • Az adatmodell, az adattípusok, az adatkapcsolatok és a tervezett lekérdezési modell erősen befolyásolja az adatplatformokkal kapcsolatos döntéseket.

    • Az alkalmazásnak szüksége van relációs adatmodellre, vagy támogatja a változósémát vagy a nem relációs adatmodellt?
    • Hogyan kérdezi le az alkalmazás az adatokat? És függnek-e a lekérdezések az adatbázisréteggel kapcsolatos fogalmaktól, például a relációs illesztésektől? Vagy az alkalmazás biztosít ilyen szemantikát?

  • Az alkalmazás által figyelembe vett adathalmazok természete változatos lehet a strukturálatlan tartalmaktól, például képektől és videóktól, vagy több strukturált fájltól, például a CSV-től és a Parquettől.

    • Az összetett alkalmazások számítási feladatai általában különböző adatkészletekkel és kapcsolódó követelményekkel rendelkeznek.

  • A relációs vagy nem relációs adatplatformokon kívül a gráf- vagy kulcs-érték adatplatformok bizonyos adatterhelésekhez is alkalmasak lehetnek.

    • Egyes technológiák a változóséma-adatmodelleket használják, ahol az adatelemek szemantikailag hasonlóak, és/vagy együtt vannak tárolva és lekérdezve, de szerkezetileg eltérnek egymástól.

  • Mikroszolgáltatási architektúrákban az egyes alkalmazásszolgáltatások különálló, forgatókönyvre optimalizált adattárakkal hozhatók létre, nem pedig egyetlen monolitikus adattártól függően.

    • Az olyan tervezési minták, mint a SAGA , alkalmazhatók a különböző adattárak közötti konzisztencia és függőségek kezelésére.
      • Az adatbázisok közötti közvetlen lekérdezések társhely-korlátozásokat is alkalmazhatnak.
    • Több adattechnológia használata bizonyos mértékű felügyeleti többletterhelést okoz a teljes technológiák fenntartásához.

  • Az egyes Azure-szolgáltatások funkciókészletei különböző nyelveken, SDK-kban és API-kban különböznek, ami nagyban befolyásolhatja az alkalmazható konfigurációhangolás szintjét.

  • Az adatmodellhez és az adattípusokhoz való optimalizált igazítás képességei erősen befolyásolják az adatplatformokkal kapcsolatos döntéseket.

    • Lekérdezési rétegek, például tárolt eljárások és objektum-relációs leképezők.
    • Nyelvsemleges lekérdezési képesség, például biztonságos REST API-réteg.
    • Üzletmenet-folytonossági képességek, például biztonsági mentés és visszaállítás.

  • Az elemzési adattárak általában támogatják a többplatformos tárolást a különböző típusú adatstruktúrákhoz.

    • Az elemzési futtatókörnyezetek, például az Apache Spark integrációs korlátozásokkal elemezhetik a többplatformos adatstruktúrákat.

  • Vállalati környezetben a meglévő folyamatok és eszközök használata, valamint a készségek folytonossága jelentős hatással lehet az adatplatform kialakítására és az adattechnológiák kiválasztására.

Valóságnak

  • Az alkalmazáson belüli adatok pontosságának ellenőrzéséhez több tényezőt is figyelembe kell venni, és ezeknek a tényezőknek a kezelése jelentős hatással lehet az adatplatform kialakítására.

    • Adatkonzisztencia.
    • Platformbiztonsági funkciók.
    • Adatszabályozás.
    • Változáskezelés és sémafejlődés.
    • Adathalmazok közötti függőségek.

  • A több adatreplikát tartalmazó elosztott alkalmazások esetében a konzisztencia és a késés között kompromisszumok vannak a CAP és a PACELC-tételben kifejezett módon.

    • Ha az olvasók és az írók eltérően vannak elosztva, az alkalmazásnak vagy az adatelem leggyorsabb elérhető verzióját kell visszaadnia, még akkor is, ha az elavult az adott adatelem egy másik replikában lévő, csak befejezett írási (frissítési) írásával vagy az adatelem legfrissebb verziójával összehasonlítva, ami további késéssel járhat a legújabb állapot meghatározásához és beszerzéséhez.
    • A konzisztencia és a rendelkezésre állás platformszinten vagy egyéni adatkérési szinten konfigurálható.
    • Mi a felhasználói élmény, ha az adatokat a felhasználóhoz legközelebbi replika szolgáltatja, amely nem tükrözi egy másik replika legutóbbi állapotát? vagyis az alkalmazás támogatja-e az elavult adatok kiszolgálását?

  • Többrégiós írási környezetben, ha ugyanazt az adatelemet két külön írási replikában módosítják, mielőtt bármelyik módosítás replikálható lenne, ütközés jön létre, amelyet fel kell oldani.

    • Szabványosított ütközésfeloldási szabályzatok, például "Utolsó írási győzelmek" vagy egyéni logikával rendelkező egyéni stratégia alkalmazhatók.

  • A biztonsági követelmények végrehajtása hátrányosan befolyásolhatja az átviteli sebességet vagy a teljesítményt.

  • Az inaktív adatok titkosítása az alkalmazásrétegben ügyféloldali titkosítással és/vagy szükség esetén kiszolgálóoldali titkosítással valósítható meg.

  • Az Azure különböző titkosítási modelleket támogat, beleértve a kiszolgálóoldali titkosítást, amely szolgáltatás által felügyelt kulcsokat, Key Vault ügyfél által kezelt kulcsokat vagy ügyfél által felügyelt kulcsokat használ az ügyfél által vezérelt hardveren.

    • Az ügyféloldali titkosítással a kulcsok Key Vault vagy más biztonságos helyen kezelhetők.

  • A MACsec (IEEE 802.1AE MAC) adatkapcsolat-titkosítás a Microsoft gerinchálózatán található Azure-adatközpontok közötti összes adatforgalom védelmére szolgál.

    • A csomagok küldése előtt a rendszer titkosítja és visszafejti a csomagokat az eszközökön, megakadályozva a fizikai "közbeékelt" vagy a snooping/wiretapping támadásokat.

  • Hitelesítés és engedélyezés az adatsíkon és a vezérlősíkon.

    • Hogyan hitelesíti és engedélyezi az adatplatform az alkalmazáshoz való hozzáférést és a működési hozzáférést?

  • Megfigyelhetőség a monitorozási platform állapot- és adathozzáférésén keresztül.

    • Hogyan történik a riasztás alkalmazása az elfogadható működési határokon kívül eső feltételekre?

Tervezési javaslatok

Kötet

  • Győződjön meg arról, hogy az organikus növekedéssel társított jövőbeli adatmennyiségek várhatóan nem lépik túl az adatplatform képességeit.

    • Előrejelzett adatnövekedési arányok az üzleti tervekhez igazítva, és a meglévő arányok használatával tájékoztatják a folyamatos kapacitásigényeket.
    • Hasonlítsa össze az összesítő és adatrekordonkénti köteteket az adatplatform korlátaival.
    • Ha fennáll a veszélye annak, hogy kivételes körülmények között korlátokat érnek el, győződjön meg arról, hogy az állásidő és az adatvesztés megelőzése érdekében működési kockázatcsökkentések vannak érvényben.

  • Monitorozza az adatmennyiséget, és ellenőrizze azt egy kapacitásmodellen, figyelembe véve a skálázási korlátokat és a várható adatnövekedési arányokat.

    • Gondoskodjon arról, hogy a méretezési műveletek összhangban legyenek a tárolási, teljesítmény- és konzisztenciakövetelményekkel.
    • Új skálázási egység bevezetésekor előfordulhat, hogy a mögöttes adatokat replikálni kell, ami időt vesz igénybe, és valószínűleg teljesítménybüntetést von maga után a replikáció során. Ezért győződjön meg arról, hogy ezeket a műveleteket a kritikus munkaidőn kívül hajtják végre, ha lehetséges.

  • Az alkalmazás adatszintjeinek meghatározása az adathalmazok használat és kritikusság alapján történő besorolásához, hogy megkönnyítse a régebbi adatok eltávolítását vagy kiszervezését.

    • Fontolja meg az adathalmazok "gyakori", "meleg" és "hideg" (archív) rétegbe való besorolását.
      • Az alapvető referencia-implementációk például az Azure Cosmos DB-t használják az alkalmazás által aktívan használt "gyakori elérésű" adatok tárolására, míg az Azure Storage a "ritka elérésű" műveleti adatok elemzési célú tárolására szolgál.

  • Konfigurálja a háztartáskezelési eljárásokat az adatnövekedés optimalizálásához, valamint az adatok hatékonyságának növeléséhez, például a lekérdezési teljesítményhez és az adatbővítés kezeléséhez.

    • Az élettartam (TTL) lejáratának konfigurálása olyan adatokhoz, amelyekre már nincs szükség, és nem rendelkezik hosszú távú elemzési értékkel.
      • Győződjön meg arról, hogy a régi adatok biztonságosan rétegezhetők másodlagos tárolókba, vagy véglegesen törölhetők anélkül, hogy az káros hatással lenne az alkalmazásra.
    • Töltse ki a nem kritikus adatokat a másodlagos hűtőtárolásba, de az elemzési érték érdekében és az auditkövetelményeknek való megfelelés érdekében tárolja őket.
    • Gyűjtse össze az adatplatform telemetriai és használati statisztikáit, hogy a DevOps-csapatok folyamatosan értékelhessék a háztartásra vonatkozó követelményeket és a "megfelelő méretű" adattárakat.

  • A mikroszolgáltatás-alkalmazások tervezésével összhangban fontolja meg több különböző adattechnológia párhuzamos használatát, és optimalizált adatmegoldásokat kínál adott számítási feladatok forgatókönyveihez és kötetkövetelményeihez.

    • Ne hozzon létre egyetlen monolitikus adattárat, ahol a bővítésből származó adatmennyiséget nehéz kezelni.

Sebesség

  • Az adatplatformot eredendően úgy kell megtervezni és konfigurálni, hogy támogassa a nagy átviteli sebességet, a számítási feladatokat különböző környezetekbe kell elválasztani a teljesítmény maximalizálása érdekében a forgatókönyvoptimalizált adatmegoldások használatával.

    • Győződjön meg arról, hogy az egyes adatforgatókönyvek olvasási és írási átviteli sebessége a várt terhelési minták szerint skálázható, és elegendő tűréshatárral rendelkezik a váratlan eltérésekkel szemben.
    • Különböző adatterheléseket, például tranzakciós és elemzési műveleteket külön teljesítménykörnyezetekbe kell elkülöníteni.

  • Terhelésszint az aszinkron, nem blokkoló üzenetküldés használatával, például a CQRS vagy az Event Sourcing minták használatával.

    • Előfordulhat, hogy késés tapasztalható az írási kérelmek és az új adatok olvasásra való elérhetővé válása között, ami hatással lehet a felhasználói élményre.
      • Ezt a hatást meg kell érteni és elfogadhatónak kell lennie a legfontosabb üzleti követelmények kontextusában.

  • A rugalmas méretezhetőség biztosítása a változó átviteli sebesség és a terhelési szintek támogatásához.

    • Ha a terhelési szintek rendkívül változékonyak, fontolja meg a kapacitásszintek túlbontását az átviteli sebesség és a teljesítmény fenntartása érdekében.
    • Tesztelje és ellenőrizze az összetett alkalmazás számítási feladataira gyakorolt hatást, ha az átviteli sebesség nem tartható fenn.

  • Az Azure-natív adatszolgáltatások rangsorolása automatizált skálázási műveletekkel, hogy megkönnyítse a terhelésszintű volatilitásra való gyors reagálást.

    • Konfigurálja az automatikus skálázást a szolgáltatáson belüli és az alkalmazás által beállított küszöbértékek alapján.
    • A skálázásnak az üzleti követelményeknek megfelelő időkeretekben kell elindulnia és végre kell hajtania.
    • Olyan forgatókönyvek esetén, ahol manuális interakcióra van szükség, hozzon létre automatikusan működő "forgatókönyveket", amelyek a manuális műveleti műveletek végrehajtása helyett aktiválhatók.
      • Fontolja meg, hogy az automatizált eseményindítók alkalmazhatók-e a későbbi mérnöki beruházások részeként.

  • Monitorozza az alkalmazásadatok olvasási és írási átviteli sebességét a P50/P99 késési követelményeknek megfelelően, és igazodjon egy alkalmazáskapacitási modellhez.

  • A többlet átviteli sebességet az adatplatformnak vagy az alkalmazásrétegnek kell kezelnie, és az állapotmodellnek kell rögzítenie a működési ábrázoláshoz.

  • A "gyakori elérésű" adatforgatókönyvek gyorsítótárazásának implementálása a válaszidő minimalizálása érdekében.

    • A gyorsítótár lejáratára és a házon tartásra vonatkozó megfelelő szabályzatok alkalmazása az elszabadult adatok növekedésének elkerülése érdekében.
      • A háttéradatok változásakor lejárnak a gyorsítótárelemek.
      • Ha a gyorsítótár lejárata szigorúan az élettartamon (TTL) alapul, meg kell érteni az elavult adatok kiszolgálásának hatását és felhasználói élményét.

Különböző

  • A felhőalapú és az Azure-natív kialakítás elvével összhangban erősen ajánlott a felügyelt Azure-szolgáltatások rangsorolása az üzemeltetési és felügyeleti összetettség csökkentése és a Microsoft jövőbeli platformberuházásainak kihasználása érdekében.

  • A lazán összekapcsolt mikroszolgáltatás-architektúrák alkalmazástervezési elvével összhangban lehetővé teszi, hogy az egyes szolgáltatások különböző adattárakat és forgatókönyvoptimalizált adattechnológiákat használjanak.

    • Határozza meg, hogy az alkalmazás milyen típusú adatstruktúrát fog kezelni az adott számítási feladatokhoz.
    • Ne hozzon létre függőséget egyetlen monolitikus adattárban.
      • Vegye figyelembe a SAGA tervezési mintáját, ahol az adattárak közötti függőségek léteznek.

  • Ellenőrizze, hogy a szükséges képességek elérhetők-e a kiválasztott adattechnológiákhoz.

    • Gondoskodjon a szükséges nyelvek és az SDK-képességek támogatásáról. Nem minden képesség érhető el minden nyelvhez/SDK-hoz azonos módon.

Valóságnak

  • Többrégiós adatplatform kialakítása és replikák terjesztése régiók között a maximális megbízhatóság, rendelkezésre állás és teljesítmény érdekében az adatok alkalmazásvégpontokhoz való közelebb mozgatásával.

    • Ossza el az adatreplikákat egy régión belüli Availability Zones (AZs) között (vagy használja a zónaredundáns szolgáltatási szinteket) a régión belüli rendelkezésre állás maximalizálása érdekében.

  • Ha a konzisztenciakövetelmények ezt lehetővé teszik, használjon többrégiós írási adatplatformot a teljes globális rendelkezésre állás és megbízhatóság maximalizálása érdekében.

    • Vegye figyelembe az ütközések feloldására vonatkozó üzleti követelményeket, ha ugyanazt az adatelemet két külön írási replikában módosítják, mielőtt bármelyik módosítás replikálható lenne, és így ütközést hoz létre.
      • Ahol csak lehetséges, használjon szabványos ütközésfeloldási szabályzatokat, például "Az utolsó nyer"
        • Ha egyéni logikával rendelkező egyéni stratégiára van szükség, győződjön meg arról, hogy CI/CD DevOps-eljárások vannak alkalmazva az egyéni logika kezelésére.

  • Tesztelje és ellenőrizze a biztonsági mentési és visszaállítási képességeket, valamint a feladatátvételi műveleteket a folyamatos kézbesítési folyamatokon belüli káoszteszteléssel.

  • Teljesítménymutatók futtatásával győződjön meg arról, hogy az átviteli sebességre és a teljesítménykövetelményekre nincs hatással a szükséges biztonsági képességek, például a titkosítás.

    • Győződjön meg arról, hogy a folyamatos kézbesítési folyamatok figyelembe veszik a terheléstesztelést az ismert teljesítménymutatókon.

  • A titkosítás alkalmazásakor erősen ajánlott szolgáltatás által felügyelt titkosítási kulcsokat használni a felügyeleti összetettség csökkentése érdekében.

    • Ha az ügyfél által felügyelt kulcsokra vonatkozó biztonsági követelmények vonatkoznak, győződjön meg arról, hogy a megfelelő kulcskezelési eljárásokat alkalmazza az összes figyelembe vett kulcs rendelkezésre állásának, biztonsági mentésének és rotálásának biztosítására.

Megjegyzés

A szélesebb körű szervezeti implementációval való integráció során kritikus fontosságú, hogy alkalmazásközpontú megközelítést alkalmazzon az adatplatform-összetevők alkalmazástervezésben való kiépítésére és működtetésére.

Pontosabban a megbízhatóság maximalizálása érdekében fontos, hogy az egyes adatplatform-összetevők megfelelően reagáljanak az alkalmazás állapotára olyan üzemeltetési műveletek révén, amelyek más alkalmazásösszetevőket is tartalmazhatnak. Ha például további adatplatform-erőforrásokra van szükség, akkor az adatplatform és más alkalmazásösszetevők kapacitásmodell szerinti skálázása valószínűleg további skálázási egységek kiépítésével lehetséges. Ez a megközelítés végső soron korlátozott lesz, ha egy központosított műveleti csapat kemény függőséget tapasztal az adatplatformtal kapcsolatos problémák elkülönítése érdekében.

Végső soron a központosított adatszolgáltatások (azaz a Központi INFORMATIKAI DBaaS) használata olyan működési szűk keresztmetszeteket vezet be, amelyek jelentősen akadályozzák az agilitást egy nagyrészt nem kontextualizált felügyeleti felületen keresztül, és ezeket kritikus fontosságú vagy üzleti szempontból kritikus környezetben kell elkerülni.

További referenciák

További adatplatform-útmutató az Azure-alkalmazás architektúra-útmutatóban érhető el.

Globálisan elosztott többrégiós írási adattár

Az alkalmazástervezés globálisan elosztott aktív-aktív törekvéseinek teljes körű kielégítése érdekében erősen ajánlott megfontolni egy elosztott többrégiós írási adatplatformot, ahol a különálló írható replikák módosításai szinkronizálódnak és egyesülnek az összes replika között, szükség esetén ütközésfeloldással.

Fontos

Előfordulhat, hogy a mikroszolgáltatásokhoz nem minden esetben van szükség elosztott többrégiós írási adattárra, ezért figyelembe kell venni az egyes számítási feladatok forgatókönyveinek architekturális környezetét és üzleti követelményeit.

Az Azure Cosmos DB egy globálisan elosztott és magas rendelkezésre állású NoSQL-adattárat biztosít, amely többrégiós írási lehetőségeket és konzisztenciát kínál. Az ebben a szakaszban található tervezési szempontok és javaslatok ezért az Optimális Azure Cosmos DB-használatra összpontosítanak.

Kialakítási szempontok

Azure Cosmos DB

  • Az Azure Cosmos DB tárolókban tárolja az adatokat, amelyek indexelt, soralapú tranzakciós tárolók, amelyek gyors tranzakciós olvasást és írást biztosítanak, válaszidővel, ezredmásodpercek sorrendjében.

  • Az Azure Cosmos DB több különböző API-t támogat különböző funkciókészletekkel, például SQL, Cassandra és MongoDB.

    • Az első féltől származó Azure Cosmos DB for NoSQL biztosítja a leggazdagabb szolgáltatáskészletet, és általában az API, ahol először új képességek válnak elérhetővé.

  • Az Azure Cosmos DB támogatja az átjáró- és közvetlen kapcsolati módokat, ahol a Direct lehetővé teszi a TCP-n keresztüli kapcsolódást a háttérbeli Azure Cosmos DB replikacsomópontokhoz, így kevesebb hálózati ugrással növelve a teljesítményt, míg az Átjáró HTTPS-kapcsolatot biztosít az előtérbeli átjárócsomópontokhoz.

    • A közvetlen mód csak az Azure Cosmos DB for NoSQL használatakor érhető el, és jelenleg csak .NET- és Java SDK-platformokon támogatott.

  • A rendelkezésre állási zónában engedélyezett régiókban az Azure Cosmos DB rendelkezésre állási zóna (AZ) redundancia-támogatást nyújt a régión belüli zónahibákkal szembeni magas rendelkezésre álláshoz és rugalmassághoz.

  • Az Azure Cosmos DB négy adatreplikát tart fenn egyetlen régión belül, és ha engedélyezve van a rendelkezésre állási zóna (AZ) redundancia, az Azure Cosmos DB biztosítja, hogy az adatreplikák több AZ-ben legyenek elhelyezve, hogy védelmet nyújtsanak a zónahibák ellen.

    • A Paxos konszenzusprotokollt a rendszer a régió replikáinak kvórumának elérésére alkalmazza.

  • Egy Azure Cosmos DB-fiók egyszerűen konfigurálható úgy, hogy több régióban replikálja az adatokat, hogy csökkentse az egyetlen régió elérhetetlenné válásának kockázatát.

    • A replikáció konfigurálható egyrégiós vagy többrégiós írással.
      • Egyetlen régió írása esetén a rendszer egy elsődleges "központ" régiót használ az összes írás kiszolgálásához, és ha ez a "központ" régió elérhetetlenné válik, feladatátvételi műveletet kell végrehajtani egy másik régió írhatóként való előléptetéséhez.
      • Többrégiós írás esetén az alkalmazások bármilyen konfigurált üzembehelyezési régióba írhatnak, amely replikálja a módosításokat az összes többi régió között. Ha egy régió nem érhető el, akkor a rendszer a többi régiót használja az írási forgalom kiszolgálására.

  • Többrégiós írási konfigurációban frissítési (beszúrási, csere- és törlési) ütközések fordulhatnak elő, ha az írók egyszerre frissítik ugyanazt az elemet több régióban.

  • Az Azure Cosmos DB két ütközésfeloldási szabályzatot biztosít, amelyek az ütközések automatikus kezelésére alkalmazhatók.

    • A Last Write Wins (LWW) egy időszinkronizálási óraprotokollt alkalmaz, amely rendszer által definiált időbélyeg _ts tulajdonságot használ ütközésfeloldási útvonalként. Ütközés esetén az ütközésfeloldási útvonal legmagasabb értékével rendelkező elem lesz a nyertes, és ha több elem azonos numerikus értékkel rendelkezik, akkor a rendszer kiválaszt egy nyertest, hogy minden régió konvergáljon a véglegesített elem ugyanazon verziójához.
      • Törlési ütközések esetén a törölt verzió mindig nyer az ütközések beszúrása vagy cseréje során, függetlenül az ütközésfeloldási útvonal értékétől.
      • Az utolsó írási győzelem az alapértelmezett ütközésfeloldási szabályzat.
      • Az Azure Cosmos DB for NoSQL használatakor egyéni numerikus tulajdonság, például egyéni időbélyeg-definíció használható az ütközések feloldásához.
    • Az egyéni feloldási szabályzatok lehetővé teszik, hogy az alkalmazás által definiált szemantika összeegyeztesse az ütközéseket egy regisztrált, egyesítéssel tárolt eljárással, amely automatikusan meghívódik az ütközések észlelésekor.
      • A rendszer pontosan egyszer biztosít garanciát az egyesítési eljárás végrehajtására a kötelezettségvállalási protokoll részeként.
      • Az egyéni ütközésfeloldási szabályzatok csak az Azure Cosmos DB for NoSQL-hez érhetők el, és csak a tároló létrehozásakor állíthatók be.

  • Egy többrégiós írási konfigurációban egyetlen Azure Cosmos DB "hub" régiótól függ az összes ütközésfeloldás végrehajtásához, és a Paxos konszenzusprotokollt alkalmazva kvórumot ér el a replikák között a központi régióban.

    • A platform üzenetpuffert biztosít a központi régión belüli írási ütközésekhez a terhelési szinthez, és redundanciát biztosít az átmeneti hibákhoz.
      • A puffer képes néhány percnyi, konszenzust igénylő írási frissítés tárolására.

Az Azure Cosmos DB platform stratégiai iránya, hogy eltávolítsa ezt az egyrégiós függőséget egy többrégiós írási konfigurációban történő ütközésfeloldáshoz, és egy kétfázisú Paxos-megközelítést alkalmazva globális szinten és régión belül kvórumot érjen el.

  • Az elsődleges "központ" régiót az Azure Cosmos DB által konfigurált első régió határozza meg.

    • Feladatátvétel céljából a rendszer további műholdtelepítési régiókhoz konfigurálja a prioritási sorrendet.

  • Az adatmodell és a logikai és fizikai partíciók particionálása fontos szerepet játszik az optimális teljesítmény és rendelkezésre állás elérésében.

  • Ha egyetlen írási régióval van üzembe helyezve, az Azure Cosmos DB konfigurálható az automatikus feladatátvételhez egy meghatározott feladatátvételi prioritás alapján, figyelembe véve az összes olvasási régió replikáját.

  • Az Azure Cosmos DB platform által biztosított RTO kb. 10–15 perc, amely rögzíti az Azure Cosmos DB szolgáltatás regionális feladatátvételének végrehajtásához szükséges időt, ha a központi régiót érintő katasztrofális katasztrófa történik.

    • Ez az RTO egy többrégiós írási környezetben is fontos, mivel az ütközésfeloldás egyetlen "központ" régiótól függ.
      • Ha a "központ" régió elérhetetlenné válik, a más régiókba irányuló írások meghiúsulnak az üzenetpuffer kitöltése után, mivel az ütközésfeloldás addig nem fog tudni végbejönni, amíg a szolgáltatás át nem megy, és létre nem jön egy új központrégió.

Az Azure Cosmos DB platform stratégiai iránya az RTO ~5 percre csökkentése a partíciószintű feladatátvételek engedélyezésével.

  • A helyreállítási pont célkitűzései (RPO) és a helyreállítási idő célkitűzései (RTO) konfigurálhatók konfigurálhatók konfigurálhatók konfigurálható konzisztenciaszinteken keresztül, az adatok tartóssága és az átviteli sebesség közötti kompromisszumokkal.

    • Az Azure Cosmos DB legalább 0 RTO-t biztosít a többrégiós írások nyugodt konzisztenciaszintjéhez, vagy egy 0-s RPO-t az egy írási régióval való erős konzisztencia érdekében.

  • Az Azure Cosmos DB 99,999%-os SLA-t kínál a több Azure-régióval konfigurált adatbázisfiókok írási és olvasási rendelkezésre állásához írhatóként.

    • Az SLA-t a havi üzemidő százalékos aránya jelöli, amely 100% – Átlagos hibaarányként van kiszámítva.
    • Az átlagos hibaarány a számlázási hónap egyes óráira vonatkozó hibaarányok összege, osztva a számlázási hónap összes óráinak számával, ahol a hibaarány a meghiúsult kérelmek teljes száma és az adott egyórás intervallum összes kéréseinek osztva.

  • Az Azure Cosmos DB 99,99%-os SLA-t biztosít az egyetlen Azure-régióra kiterjedő adatbázisfiókok átviteli sebességéhez, konzisztenciájához, rendelkezésre állásához és késéséhez, ha az öt konzisztenciaszint bármelyikével van konfigurálva.

    • A 99,99%-os SLA a négy nyugodt konzisztenciaszint bármelyikével konfigurált több Azure-régióra kiterjedő adatbázisfiókokra is vonatkozik.

  • Az Azure Cosmos DB-ben kétféle átviteli sebesség adható ki, a standard és az automatikus skálázás, amelyek másodpercenkénti kérelemegységek (RU/s) használatával vannak mérve.

    • A standard átviteli sebesség lefoglalja a megadott RU/s érték garantálásához szükséges erőforrásokat.
      • A standard számlázás óránként történik a kiosztott átviteli sebességért.
    • Az automatikus skálázás meghatározza a maximális átviteli sebességet, és az Azure Cosmos DB automatikusan fel- vagy leskálázódik az alkalmazás terhelésétől függően a maximális átviteli sebesség értéke és a maximális átviteli sebesség legalább 10%-a között.
      • Az automatikus skálázás számlázása óránként történik a felhasznált maximális átviteli sebességért.

  • A változó számítási feladatokkal rendelkező statikus kiosztott átviteli sebesség szabályozási hibákat eredményezhet, ami hatással lesz az észlelt alkalmazások rendelkezésre állására.

    • Az automatikus skálázás védelmet nyújt a szabályozási hibák ellen azáltal, hogy engedélyezi az Azure Cosmos DB-nek, hogy szükség szerint vertikálisan felskálázza a skálázást, miközben fenntartja a költségvédelmet a terhelés csökkenésekor visszaskálázással.

  • Ha az Azure Cosmos DB több régióban van replikálva, a kiosztott kérelemegységek (RU-k) számlázása régiónként történik.

  • Jelentős költségkülönbség van a többrégiós írási és az egyrégiós írási konfiguráció között, ami sok esetben tiltó költségűvé teheti a több fő azure Cosmos DB-adatplatformot.

Egyrégió olvasása/írása Egyrégió írása – Kettős régió olvasása Kettős régió olvasása/írása
1 RU 2 RU 4 RU

Az egyrégiós írás és a többrégiós írás közötti eltérés valójában kisebb, mint a fenti táblázatban látható 1:2 arány. Pontosabban egy régióközi adatátviteli díj van társítva az írási frissítésekhez egy írási konfigurációban, amelyet a rendszer nem rögzít a kérelemegység-költségeken belül, mint a többrégiós írási konfiguráció esetében.

  • A felhasznált tárterület átalánydíjként van kiszámlázva az adatok és indexek adott órán keresztül történő üzemeltetéséhez felhasznált teljes tárterület (GB) alapján.

  • Session az alapértelmezett és leggyakrabban használt konzisztenciaszint , mivel az adatok az írási sorrendben érkeznek.

  • Az Azure Cosmos DB támogatja a hitelesítést Microsoft Entra identitással, vagy azure Cosmos DB-kulcsokkal és erőforrás-jogkivonatokkal, amelyek egymást átfedő képességeket biztosítanak.

Az Azure Cosmos DB hozzáférési képességei

  • Az erőforrás-felügyeleti műveletek letilthatók kulcsokkal vagy erőforrás-jogkivonatokkal, hogy a kulcsokat és az erőforrás-jogkivonatokat csak az adatműveletekre korlátozzák, így lehetővé teszi a részletes erőforrás-hozzáférés-vezérlést Microsoft Entra szerepköralapú hozzáférés-vezérlés (RBAC) használatával.

    • A vezérlősík kulcsokon vagy erőforrás-jogkivonatokon keresztüli hozzáférésének korlátozása letiltja az Azure Cosmos DB SDK-t használó ügyfelek vezérlősík-műveleteit, ezért alaposan ki kell értékelni és tesztelni kell.
    • A disableKeyBasedMetadataWriteAccess beállítás konfigurálható ARM-sablon IaC-definíciókkal vagy beépített Azure Policy keresztül.

  • Microsoft Entra Azure Cosmos DB RBAC-támogatása a fiók- és erőforrás-vezérlésisík-kezelési műveletekre vonatkozik.

  • Az Azure Cosmos DB-erőforrások (fiókok, adatbázisok és tárolók) erőforrás-zárolásokkal védhetők a helytelen módosításokkal vagy törlésekkel szemben.

    • Az erőforrás-zárolások a fiók, az adatbázis vagy a tároló szintjén állíthatók be.
    • Az erőforráson beállított erőforrás-zárolást az összes gyermekerőforrás örökli. Az Azure Cosmos DB-fiók erőforrás-zárolási készletét például a fiók összes adatbázisa és tárolója örökli.
    • Az erőforrás-zárolások csak a vezérlősík műveleteire vonatkoznak, és nem akadályozzák meg az adatsík műveleteit, például az adatok létrehozását, módosítását vagy törlését.
    • Ha a vezérlősíkhoz való hozzáférés nincs korlátozva a paranccsal disableKeyBasedMetadataWriteAccess, akkor az ügyfelek fiókkulcsokkal végezhetnek vezérlősík-műveleteket.

  • Az Azure Cosmos DB változáscsatornája az Azure Cosmos DB-tárolóban lévő adatok változásainak időrendben rendezett hírcsatornáját biztosítja.

    • A változáscsatorna csak a beszúrási és frissítési műveleteket tartalmazza a forrás Azure Cosmos DB-tárolóra; nem tartalmaz törléseket.

  • A változáscsatorna az alkalmazás által használt elsődleges tárolótól eltérő adattár fenntartására használható, a céladattár folyamatos frissítéseivel, amelyeket a forrástároló változáscsatornája táplál.

    • A változáscsatorna felhasználható egy másodlagos tároló feltöltésére további adatplatform-redundancia vagy az azt követő elemzési forgatókönyvek esetében.

  • Ha a törlési műveletek rutinszerűen befolyásolják a forrástárolón belüli adatokat, akkor a változáscsatorna által táplált tároló pontatlan és nem reagál a törölt adatokra.

    • Helyreállítható törlési minta implementálható, hogy az adatrekordok bekerülhessenek a változáscsatornába.
      • Az adatrekordok explicit törlése helyett az adatrekordok frissülnek egy jelző (például IsDeleted) beállításával, amely jelzi, hogy az elem töröltnek minősül.
      • A változáscsatorna által táplált céladattáraknak észlelnie és feldolgoznia kell azokat az elemeket, amelyek törölt jelzője True (Igaz) értékre van állítva; A helyreállíthatóan törölt adatrekordok tárolása helyett a céltárolóban lévő adatrekord meglévő verzióját kell törölni.
    • A rendszer általában egy rövid élettartamot (TTL) használ a helyreállítható törlési mintával, így az Azure Cosmos DB automatikusan törli a lejárt adatokat, de csak azután, hogy az tükröződik a változáscsatornában, és a törölt jelző Értéke Igaz.
      • Végrehajtja az eredeti törlési szándékot, miközben a törlést a változáscsatornán keresztül is propagálja.

  • Az Azure Cosmos DB konfigurálható elemzési tárolóként, amely oszlopformátumot alkalmaz az optimalizált elemzési lekérdezésekhez a hagyományos ETL-folyamatokkal kapcsolatos összetettségi és késési kihívások kezelésére.

  • Az Azure Cosmos DB automatikusan biztonsági másolatot készít az adatokról rendszeres időközönként anélkül, hogy ez hatással van a teljesítményre vagy a rendelkezésre állásra, és ne használná az RU/s-t.

  • Az Azure Cosmos DB két különböző biztonsági mentési mód szerint konfigurálható.

    • Az időszakos az összes fiók alapértelmezett biztonsági mentési módja, ahol a biztonsági másolatok rendszeres időközönként készülnek, és az adatok a támogatási csapattal létrehozott kéréssel állíthatók vissza.
      • Az alapértelmezett rendszeres biztonsági mentési megőrzési időszak nyolc óra, az alapértelmezett biztonsági mentési időköz pedig négy óra, ami azt jelenti, hogy alapértelmezés szerint csak a legutóbbi két biztonsági mentés van tárolva.
      • A biztonsági mentési időköz és a megőrzési időtartam konfigurálható a fiókon belül.
        • A maximális megőrzési időtartam egy hónapra terjed ki, amelynek minimális biztonsági mentési időköze egy óra.
        • A biztonsági mentési tár redundanciának konfigurálásához szerepkör-hozzárendelés szükséges az Azure "Cosmos DB-fiókolvasó szerepköréhez".
      • Két biztonsági mentési példányt külön költség nélkül foglalunk bele, de a további biztonsági másolatok további költségekkel járnak.
      • Alapértelmezés szerint az időszakos biztonsági mentések külön Geo-Redundant Storage -ben (GRS) vannak tárolva, amelyek nem érhetők el közvetlenül.
        • A biztonsági mentési tároló az elsődleges "központ" régióban található, és a mögöttes tárreplikáláson keresztül replikálódik a párosított régióba.
        • A mögöttes biztonsági mentési tárfiók redundanciakonfigurációja zónaredundáns tárolóra vagy Locally-Redundant Storage-ra konfigurálható.
      • A visszaállítási művelet végrehajtásához támogatási kérésre van szükség, mivel az ügyfelek nem hajthatnak végre közvetlenül visszaállítást.
        • A támogatási jegy megnyitása előtt a biztonsági másolatok adatmegőrzési időtartamát az adatvesztési eseményt követő nyolc órán belül legalább hét napra kell növelni.
      • A visszaállítási művelet létrehoz egy új Azure Cosmos DB-fiókot, ahol az adatok helyreállnak.
        • Egy meglévő Azure Cosmos DB-fiók nem használható visszaállításhoz
        • Alapértelmezés szerint egy új nevű <Azure_Cosmos_account_original_name>-restored<n> Azure Cosmos DB-fiók lesz használatban.
          • Ez a név módosítható, például a meglévő név újbóli használatával, ha az eredeti fiókot törölték.
      • Ha az átviteli sebesség adatbázisszinten van kiépítve, a biztonsági mentés és a visszaállítás az adatbázis szintjén történik
        • A visszaállítandó tárolók egy részhalmazát nem lehet kiválasztani.
    • A folyamatos biztonsági mentési mód lehetővé teszi az elmúlt 30 nap bármely időpontra történő visszaállítását.
      • A visszaállítási műveletek egy másodperces részletességgel, egy adott időpontra (PITR) való visszatérésre hajthatók végre.
      • A visszaállítási műveletekhez rendelkezésre álló időszak legfeljebb 30 nap.
        • Az erőforrás példányosítási állapotára is visszaállítható.
      • A folyamatos biztonsági mentések minden olyan Azure-régióban készülnek, ahol az Azure Cosmos DB-fiók létezik.
        • A folyamatos biztonsági mentések ugyanabban az Azure-régióban vannak tárolva, mint az egyes Azure Cosmos DB-replikák, Locally-Redundant Storage (LRS) vagy zónaredundáns tárolás (ZRS) használatával a Availability Zones támogató régiókban.
      • Az önkiszolgáló visszaállítás a Azure Portal vagy IaC-összetevőkkel, például ARM-sablonokkal végezhető el.
      • A folyamatos biztonsági mentésnek több korlátozása is van.
        • A folyamatos biztonsági mentési mód jelenleg nem érhető el többrégiós írási konfigurációban.
        • Jelenleg csak a NoSQL-hez készült Azure Cosmos DB és a MongoDB-hez készült Azure Cosmos DB konfigurálható folyamatos biztonsági mentésre.
        • Ha egy tároló TTL-t konfigurált, a TTL-t túllépő visszaállított adatok azonnal törölhetők
      • A visszaállítási művelet létrehoz egy új Azure Cosmos DB-fiókot az időponthoz kötött visszaállításhoz.
      • A folyamatos biztonsági mentési és visszaállítási műveletek esetében további tárolási költségek merülnek fel.

  • A meglévő Azure Cosmos DB-fiókok áttelepíthetők időszakosról folyamatosra, folyamatosról időszakosra azonban nem; a migrálás egyirányú és nem visszafordítható.

  • Minden Azure Cosmos DB biztonsági mentés magában az adatokból és a kiosztott átviteli sebesség konfigurációs részleteiből, az indexelési szabályzatokból, az üzembehelyezési régió(k)ból és a tároló TTL-beállításaiból áll.

  • Egyéni biztonsági mentési és visszaállítási képességek implementálhatók olyan helyzetekben, amikor az időszakos és folyamatos megközelítések nem megfelelőek.

    • Az egyéni megközelítés jelentős költségeket és további adminisztratív többletterheket vezet be, amelyeket meg kell érteni és alaposan meg kell vizsgálni.
      • Gyakori visszaállítási forgatókönyveket kell modellezni, például egy fiók, adatbázis, tároló sérülését vagy törlését az adatelemen.
      • A biztonsági másolatok betörésének megakadályozása érdekében takarítási eljárásokat kell végrehajtani.
    • Az Azure Storage vagy egy alternatív adattechnológia is használható, például egy alternatív Azure Cosmos DB-tároló.
      • Az Azure Storage és az Azure Cosmos DB natív integrációt biztosít az Azure-szolgáltatásokkal, például Azure Functions és Azure Data Factory.

  • Az Azure Cosmos DB dokumentációja két lehetséges lehetőséget jelöl az egyéni biztonsági mentések implementálására.

    • Az Azure Cosmos DB változáscsatornája úgy változik , hogy adatokat írjon egy különálló tárolóhelyre.
    • Mind a folyamatos, mind az időszakos (kötegelt) egyéni biztonsági mentések implementálhatók a változáscsatorna használatával.
    • Az Azure Cosmos DB változáscsatornája még nem tükrözi a törléseket, ezért logikai tulajdonság és TTL használatával kell helyreállítható törlési mintát alkalmazni.
      • Erre a mintára nem lesz szükség, ha a változáscsatorna teljes körű frissítéseket biztosít.
    • Azure Data Factory Connector for Azure Cosmos DB (Azure Cosmos DB for NoSQL vagy MongoDB API-összekötők) az adatok másolásához.
      • Azure Data Factory (ADF) támogatja a manuális végrehajtást és az ütemezést, az átfedésmentes ablakokat és az eseményalapú eseményindítókat.
        • Támogatja a Storage és az Event Grid szolgáltatást is.
      • Az ADF elsősorban a kötegorientált vezénylés miatt alkalmas az egyéni biztonsági mentések rendszeres implementálására.
        • A vezénylés végrehajtásának többletterhelése miatt kevésbé alkalmas folyamatos biztonsági mentési implementációkhoz gyakori eseményekkel.
      • Az ADF támogatja a Azure Private Link magas hálózati biztonsági forgatókönyvekhez

Az Azure Cosmos DB-t számos Azure-szolgáltatás tervezése során használják, így az Azure Cosmos DB jelentős regionális szolgáltatáskimaradása kaszkádolt hatással lesz a régión belüli különböző Azure-szolgáltatásokra. Az adott szolgáltatásra gyakorolt pontos hatás nagyban függ attól, hogy a mögöttes szolgáltatás kialakítása hogyan használja az Azure Cosmos DB-t.

Tervezési javaslatok

Azure Cosmos DB

  • Használja az Azure Cosmos DB-t elsődleges adatplatformként, ahol a követelmények lehetővé teszik.

  • Kritikus fontosságú számítási feladatok esetén konfigurálja az Azure Cosmos DB-t egy írási replikával az egyes üzembehelyezési régiókban a késés csökkentése és a maximális redundancia biztosítása érdekében.

    • Konfigurálja az alkalmazást úgy, hogy rangsorolja a helyi Azure Cosmos DB-replika használatát az írásokhoz és olvasásokhoz az alkalmazásterhelés, a teljesítmény és a regionális RU/s-használat optimalizálása érdekében.
    • A többrégiós írási konfiguráció jelentős költséggel jár, és csak a maximális megbízhatóságot igénylő számítási feladatok esetében kell rangsorolásra kerülni.

  • A kevésbé kritikus számítási feladatok esetében fontossági sorrendbe kell írni az egyrégiós írási konfigurációt (Availability Zones használatakor) a globálisan elosztott olvasási replikákkal, mivel ez az adatplatform magas szintű megbízhatóságát kínálja (99,999%-os SLA az olvasáshoz, 99,995%-os SLA írási műveletekhez) egy meggyőzőbb ár-ponttal.

    • Konfigurálja az alkalmazást úgy, hogy a helyi Azure Cosmos DB olvasási replikát használja az olvasási teljesítmény optimalizálásához.

  • Válasszon ki egy optimális "központi" üzembehelyezési régiót, ahol ütközésfeloldás történik egy többrégiós írási konfigurációban, és minden írás egy régiónkénti írási konfigurációban lesz végrehajtva.

    • Vegye figyelembe a más üzembehelyezési régiókhoz viszonyított távolságot és a kapcsolódó késést az elsődleges régió kiválasztásakor, valamint az olyan szükséges képességeket, mint a Availability Zones támogatás.

  • Konfigurálja az Azure Cosmos DB-t rendelkezésreállási zóna (AZ) redundanciával az összes üzembehelyezési régióban az AZ-támogatással, hogy biztosítsa a régión belüli zónaszintű hibákkal szembeni rugalmasságot.

  • Használja az Azure Cosmos DB for NoSQL-t, mivel a legátfogóbb funkciókészletet kínálja, különösen a teljesítmény finomhangolása esetén.

    • Az alternatív API-kat elsősorban a migrálási vagy kompatibilitási forgatókönyvek esetében kell figyelembe venni.
      • Alternatív API-k használata esetén ellenőrizze, hogy a szükséges képességek elérhetők-e a kiválasztott nyelvvel és SDK-val az optimális konfiguráció és teljesítmény biztosítása érdekében.

  • A közvetlen kapcsolati móddal optimalizálhatja a hálózati teljesítményt a háttérbeli Azure Cosmos DB-csomópontokhoz való közvetlen TCP-kapcsolaton keresztül, csökkentett számú hálózati ugrással.

Az Azure Cosmos DB SLA-t a meghiúsult kérések átlagolása számítja ki, amelyek nem feltétlenül igazodnak közvetlenül a 99,999%-os megbízhatósági szint hibakeretéhez. A 99,999%-os SLO tervezésekor ezért elengedhetetlen a regionális és többrégiós Azure Cosmos DB írási elérhetetlenségének megtervezése, így biztosítva, hogy hiba esetén tartalék tárolási technológia legyen elhelyezve, például egy üzenetsor megőrzése a későbbi visszajátszáshoz.

  • Particionálási stratégia definiálása a logikai és fizikai partíciók között az adatmodellnek megfelelő adateloszlás optimalizálásához.

    • Minimalizálja a több partícióra kiterjedő lekérdezések számát.
    • Iteratívan tesztelje és ellenőrizze a particionálási stratégiát az optimális teljesítmény biztosítása érdekében.

  • Válasszon ki egy optimális partíciókulcsot.

    • A partíciókulcs nem módosítható, miután létrejött a gyűjteményben.
    • A partíciókulcsnak olyan tulajdonságértéknek kell lennie, amely nem változik.
    • Válasszon ki egy magas számosságú partíciókulcsot, amely számos lehetséges értékkel rendelkezik.
    • A partíciókulcsnak egyenletesen kell elosztania az ru-használatot és az adattárolást az összes logikai partíción, hogy a fizikai partíciók között egyenletesen lehessen kihasználni az ru-használatot és a tárolóelosztást.
    • Futtasson olvasási lekérdezéseket a particionált oszlopon a kérelemegység-használat és a késés csökkentése érdekében.

  • Az indexelés a teljesítmény szempontjából is kulcsfontosságú, ezért győződjön meg arról, hogy az indexkizárások az RU/s és a tárolási követelmények csökkentésére szolgálnak.

    • Csak azokat a mezőket indexelje, amelyek a lekérdezéseken belüli szűréshez szükségesek; a leggyakrabban használt predikátumok indexeinek tervezése.

  • Használja ki az Azure Cosmos DB SDK beépített hibakezelési, újrapróbálkozési és szélesebb körű megbízhatósági képességeit.

  • A szolgáltatás által felügyelt titkosítási kulcsok használatával csökkentheti a felügyelet összetettségét.

    • Ha az ügyfél által felügyelt kulcsokra vonatkozó biztonsági követelmények vonatkoznak, győződjön meg arról, hogy megfelelő kulcskezelési eljárásokat alkalmaz, például a biztonsági mentést és a rotációt.

  • Tiltsa le az Azure Cosmos DB kulcsalapú metaadat-írási hozzáférését a beépített Azure Policy alkalmazásával.

  • Engedélyezze az Azure Monitor számára a főbb metrikák és diagnosztikai naplók gyűjtését, például a kiosztott átviteli sebességet (RU/s).

    • Az Azure Monitor üzemeltetési adatainak átirányítása egy Azure Cosmos DB-hez és más globális erőforrásokhoz dedikált Log Analytics-munkaterületre az alkalmazásterven belül.
    • Az Azure Monitor-metrikák használatával állapítsa meg, hogy az alkalmazás forgalmi mintái alkalmasak-e az automatikus skálázásra.

  • Értékelje ki az alkalmazás forgalmi mintáit a kiosztott átviteli sebességtípusok optimális beállításának kiválasztásához.

    • Fontolja meg a kiosztott átviteli sebesség automatikus skálázását a számítási feladatok igényének automatikus simításához.

  • Értékelje ki a Microsoft Azure Cosmos DB-hez készült teljesítménytippeit , hogy optimalizálja az ügyféloldali és kiszolgálóoldali konfigurációt a nagyobb késés és az átviteli sebesség érdekében.

  • Ha az AKS-t használja számítási platformként: Lekérdezésigényes számítási feladatok esetén válasszon ki egy AKS-csomópont termékváltozatát, amely lehetővé tette a gyorsított hálózatkezelést a késés és a PROCESSZOR-jitterek csökkentése érdekében.

  • Az egy írási régióban üzemelő üzemelő példányok esetében erősen ajánlott az Azure Cosmos DB konfigurálása az automatikus feladatátvételhez.

  • Terhelésszint az aszinkron, nem blokkoló üzenetküldés használatával a rendszerfolyamatokban, amelyek frissítéseket írnak az Azure Cosmos DB-be.

  • Konfigurálja az Azure Cosmos DB-fiókot a folyamatos biztonsági mentésekhez, hogy az elmúlt 30 nap helyreállítási pontjainak részletessége elérhető legyen.

    • Fontolja meg az Azure Cosmos DB biztonsági mentések használatát olyan esetekben, amikor a tartalmazott adatok vagy az Azure Cosmos DB-fiók törlődnek vagy sérültek.
    • Kerülje az egyéni biztonsági mentési módszer használatát, kivéve, ha feltétlenül szükséges.

  • Erősen ajánlott a helyreállítási eljárásokat nem éles erőforrásokon és adatokon gyakorolni a standard üzletmenet-folytonossági műveletek előkészítése részeként.

  • Definiálja az IaC-összetevőket az Azure Cosmos DB biztonsági mentési visszaállítás konfigurációs beállításainak és képességeinek újbóli létrehozásához.

  • Értékelje ki és alkalmazza az Azure Cosmos DB biztonsági mentésére és helyreállítására vonatkozó azure-biztonsági alapkonfiguráció-vezérlési útmutatót.

  • A többrégiós rendelkezésre állást igénylő elemzési számítási feladatokhoz használja az Azure Cosmos DB Elemzési tárat, amely oszlopformátumot alkalmaz az optimalizált elemzési lekérdezésekhez.

Relációs adattechnológiák

A nagy mértékben relációs adatmodellel vagy a meglévő relációs technológiáktól való függőségekkel rendelkező forgatókönyvek esetében előfordulhat, hogy az Azure Cosmos DB használata többrégiós írási konfigurációban nem alkalmazható közvetlenül. Ilyen esetekben létfontosságú, hogy a használt relációs technológiákat úgy tervezzen és konfigurálják, hogy fenntartsa az alkalmazástervezés többrégiós aktív-aktív törekvéseit.

Az Azure számos felügyelt relációs adatplatformot biztosít, beleértve a Azure SQL Database-t és az Azure Database-t a gyakori OSS-relációs megoldásokhoz, például a MySQL-hez, a PostgreSQL-hez és a MariaDB-hez. A jelen szakaszban szereplő tervezési szempontok és javaslatok ezért a Azure SQL Database és az Azure Database OSS-ízek optimális használatára összpontosítanak a megbízhatóság és a globális rendelkezésre állás maximalizálása érdekében.

Kialakítási szempontok

  • Bár a relációs adattechnológiák konfigurálhatók az olvasási műveletek egyszerű skálázására, az írási műveletek általában egyetlen elsődleges példányra korlátozódnak, ami jelentős mértékben korlátozza a méretezhetőséget és a teljesítményt.

  • Horizontális skálázás alkalmazható az adatok és a feldolgozás több azonos strukturált adatbázis közötti elosztására, az adatbázisok horizontális particionálására a platformkorlátozások közötti navigáláshoz.

    • A horizontális skálázást például gyakran alkalmazzák több-bérlős SaaS-platformokon a bérlőcsoportok különálló adatplatform-szerkezetekbe való elkülönítéséhez.

Azure SQL Database

  • Azure SQL Database egy teljes körűen felügyelt adatbázismotort biztosít, amely mindig a SQL Server adatbázismotor és az alapul szolgáló operációs rendszer legújabb stabil verzióján fut.

    • Olyan intelligens funkciókat biztosít, mint a teljesítmény finomhangolása, a fenyegetésfigyelés és a sebezhetőségi felmérések.

  • Azure SQL Database beépített regionális magas rendelkezésre állást és kulcsrakész georeplikációt biztosít az olvasási replikák Azure-régiók közötti elosztásához.

    • A georeplikációval a másodlagos adatbázis-replikák csak olvashatók maradnak, amíg feladatátvételt nem kezdeményeznek.
    • Ugyanazon vagy különböző régiókban legfeljebb négy másodlagos fájl támogatott.
    • A másodlagos replikák írásvédett lekérdezési hozzáféréshez is használhatók az olvasási teljesítmény optimalizálása érdekében.
    • A feladatátvételt manuálisan kell elindítani, de az automatizált üzemeltetési eljárásokba burkolható.

  • Azure SQL Database automatikus feladatátvételi csoportokat biztosít, amelyek replikálják az adatbázisokat egy másodlagos kiszolgálóra, és lehetővé teszik a transzparens feladatátvételt meghibásodás esetén.

    • Az automatikus feladatátvételi csoportok támogatják a csoport összes adatbázisának georeplikációját egy másik régióban lévő egyetlen másodlagos kiszolgálóra vagy példányra.
    • Az automatikus feladatátvételi csoportok jelenleg nem támogatottak a rugalmas skálázási szolgáltatási szinten.
    • A másodlagos adatbázisok az olvasási forgalom kiszervezésére használhatók.

  • A prémium vagy üzletileg kritikus szolgáltatási szintű adatbázis-replikák további költségek nélkül terjeszthetők Availability Zones között.

    • A vezérlőgyűrű három átjárógyűrűként (GW) is duplikálva van több zónában.
      • Az adott átjárókörhöz való útválasztást az Azure Traffic Manager vezérli.
    • A üzletileg kritikus szint használatakor a zónaredundáns konfiguráció csak akkor érhető el, ha a Gen5 számítási hardver van kiválasztva.

  • Azure SQL Database alapkonfigurációjú, 99,99%-os rendelkezésre állási SLA-t kínál az összes szolgáltatási szinten, de magasabb, 99,995%-os SLA-t biztosít a rendelkezésre állási zónákat támogató régiók üzletileg kritikus vagy prémium szintjeihez.

    • Azure SQL zónaredundáns üzemelő példányokhoz nem konfigurált adatbázis-üzletileg kritikus vagy prémium szintű szintek rendelkezésre állási SLA-ja 99,99%.

  • Georeplikációval konfigurálva az Azure SQL Database üzletileg kritikus szint 30 másodperces helyreállítási időkorlátot (RTO) biztosít az üzembe helyezett órák 100%-ához.

  • Georeplikációval konfigurálva az Azure SQL Database üzletileg kritikus szint 5 másodperces helyreállítási időkorláttal (RPO) rendelkezik az üzembe helyezett órák 100%-ában.

  • Azure SQL adatbázis rugalmas skálázási szintje legalább két replikával konfigurálva 99,99%-os rendelkezésre állási SLA-val rendelkezik.

  • A Azure SQL Database-hez kapcsolódó számítási költségek foglalási kedvezmény használatával csökkenthetők.

    • A DTU-alapú adatbázisokhoz nem lehet fenntartott kapacitást alkalmazni.

  • Az időponthoz kötött visszaállítással adatbázist és tartalmazott adatokat adhat vissza egy korábbi időpontra.

  • A georedundáns visszaállítással helyreállítható egy adatbázis georedundáns biztonsági másolatból.

Azure Database For PostgreSQL

  • Az Azure Database for PostgreSQL három különböző üzembehelyezési lehetőséggel érhető el:

    • Önálló kiszolgáló, SLA 99,99%
    • Rugalmas kiszolgáló, amely 99,99%-os SLA-redundanciát kínál a rendelkezésreállási zóna redundanciájával
    • Rugalmas skálázás (Citus), SLA 99,95%, ha a magas rendelkezésre állási mód engedélyezve van.

  • A rugalmas skálázás (Citus) dinamikus skálázhatóságot biztosít az alkalmazásmódosítások nélküli horizontális skálázással.

    • A táblázatsorok több PostgreSQL-kiszolgálón való elosztása kulcsfontosságú a rugalmas skálázású (Citus) skálázható lekérdezések biztosításához.
    • Több csomópont együttesen több adatot tárolhat, mint egy hagyományos adatbázis, és sok esetben párhuzamosan használhatja a feldolgozó PROCESSZORokat a költségek optimalizálásához.

  • Az automatikus skálázás a runbookok automatizálásával konfigurálható a változó forgalmi mintákra reagáló rugalmasság biztosítása érdekében.

  • A rugalmas kiszolgáló költséghatékonyságokat biztosít a nem éles számítási feladatokhoz a kiszolgáló leállításának/elindításának lehetőségével, valamint egy olyan, a folyamatos számítási kapacitást nem igénylő számítási feladatokhoz megfelelő, rugalmas számítási szinttel.

  • A teljes kiosztott kiszolgáló tárterületének legfeljebb 100%-áért nem számítunk fel többletköltséget a biztonsági mentési tárért.

    • A biztonsági mentési tár további felhasználása a felhasznált GB/hó alapján történik.

  • A Azure Database for PostgreSQL társított számítási költségek egykiszolgálós foglalási kedvezmény vagy rugalmas skálázási (Citus) foglalási kedvezmény használatával csökkenthetők.

Tervezési javaslatok

  • Fontolja meg a relációs adatbázisok particionálását különböző alkalmazás- és adatkörnyezetek alapján, segítve a platformkorlátozások közötti navigálást, a méretezhetőség és a rendelkezésre állás maximalizálását, valamint a hibaelkülönítést.

    • Ez a javaslat különösen akkor elterjedt, ha az alkalmazás kialakítása három vagy több Azure-régiót mérlegel, mivel a relációs technológiai korlátozások jelentősen akadályozhatják a globálisan elosztott adatplatformokat.
    • A horizontális skálázás nem felel meg minden alkalmazásforgatókönyvnek, ezért környezetfüggő kiértékelésre van szükség.

  • Rangsorolja a Azure SQL Database használatát, ahol a relációs követelmények az Azure platform fejlettsége és a megbízhatósági képességek széles választéka miatt léteznek.

Azure SQL Database

  • A Business-Critical szolgáltatásszinttel maximalizálhatja a megbízhatóságot és a rendelkezésre állást, beleértve a kritikus rugalmassági képességekhez való hozzáférést.

  • A virtuálismag-alapú használati modell használatával megkönnyítheti a számítási és tárolási erőforrások független kiválasztását, a számítási feladatok mennyiségére és átviteli sebességére vonatkozó követelményekhez igazítva.

    • Győződjön meg arról, hogy egy meghatározott kapacitásmodell van alkalmazva a számítási és tárolási erőforrások követelményeinek tájékoztatásához.

  • Konfigurálja a Zone-Redundant üzembehelyezési modellt úgy, hogy üzletileg kritikus adatbázis-replikákat terjesszen el ugyanazon a régión belül Availability Zones.

  • Az aktív georeplikációval olvasható replikákat helyezhet üzembe az összes üzembehelyezési régióban (legfeljebb négyen).

  • Az automatikus feladatátvételi csoportok használatával transzparens feladatátvételt biztosíthat egy másodlagos régióba, és georeplikációt alkalmazva további üzembehelyezési régiókba replikálhatja az olvasási optimalizálást és az adatbázis-redundanciát.

    • A csak két üzembehelyezési régióra korlátozott alkalmazásforgatókönyvek esetében az automatikus feladatátvételi csoportok használatát kell előnyben részesíteni.

  • Az automatikus feladatátvételi csoport elsődleges és másodlagos példányát érintő hiba esetén fontolja meg az alkalmazásállapot-modellhez igazított riasztáson alapuló automatizált műveleti eseményindítók elvégzését a georeplikált példányok feladatátvételéhez.

Fontos

A négynél több üzembehelyezési régiót fontolgató alkalmazások esetében komolyan figyelembe kell venni az alkalmazás hatókörön belüli horizontális skálázását vagy az alkalmazás újrabontását a többrégiós írási technológiák, például az Azure Cosmos DB támogatása érdekében. Ha azonban ez nem valósítható meg az alkalmazás számítási feladatainak forgatókönyvében, javasoljuk, hogy emeljen egy régiót egyetlen földrajzi helyen belül egy elsődleges állapotra, amely magában foglalja a georeplikált példányt egyenletesebb elosztott olvasási hozzáférésre.

  • Konfigurálja az alkalmazást replikapéldányok lekérdezésére olvasási lekérdezésekhez az olvasási teljesítmény optimalizálása érdekében.

  • Az Azure Monitor és a Azure SQL Analytics használatával közel valós idejű üzemeltetési megállapításokat kaphat Azure SQL DB-ben a megbízhatósági incidensek észleléséhez.

  • Az Azure Monitor használatával kiértékelheti az összes adatbázis használatát annak megállapításához, hogy megfelelően lettek-e méretezve.

    • Győződjön meg arról, hogy a CD-folyamatok a megfelelő adatplatform-viselkedés ellenőrzéséhez figyelembe veszik a jellemző terhelési szinteken végzett terheléstesztelést.

  • Az adatbázis-összetevők állapotmetrikáinak kiszámítása az üzleti követelményekhez és az erőforrás-kihasználtsághoz viszonyítva, monitorozás és riasztások használatával, adott esetben az automatizált üzemeltetési műveletek végrehajtásához.

    • Győződjön meg arról, hogy a fő lekérdezési teljesítménymetrikák be vannak építve, hogy gyors műveletet lehessen tenni a szolgáltatás romlása esetén.

  • Optimalizálhatja a lekérdezéseket, táblákat és adatbázisokat a Lekérdezési terheléselemzők és a Microsoft által biztosított gyakori teljesítményjavaslatok használatával.

  • Implementáljon újrapróbálkozási logikát az SDK használatával az adatbázis Azure SQL-kapcsolatra hatással lévő átmeneti hibák elhárításához.

  • Rangsorolja a szolgáltatás által felügyelt kulcsok használatát a kiszolgálóoldali transzparens adattitkosítás (TDE) inaktív titkosításhoz való alkalmazásakor.

    • Ha ügyfél által felügyelt kulcsokra vagy ügyféloldali (AlwaysEncrypted) titkosításra van szükség, győződjön meg arról, hogy a kulcsok megfelelően rugalmasak a biztonsági mentésekkel és az automatikus rotációs lehetőségekkel.

  • Fontolja meg az időponthoz kötött visszaállítás operatív forgatókönyvként való használatát a súlyos konfigurációs hibák utáni helyreállításhoz.

Azure Database For PostgreSQL

  • A rugalmas kiszolgálót ajánlott üzletileg kritikus számítási feladatokhoz használni a rendelkezésre állási zóna támogatása miatt.

  • Ha rugalmas skálázást (Citus) használ az üzletileg kritikus számítási feladatokhoz, engedélyezze a magas rendelkezésre állási módot, hogy megkapja a 99,95%-os SLA-garanciát.

  • A rugalmas skálázási (Citus) kiszolgálókonfigurációval maximalizálhatja a rendelkezésre állást több csomópont között.

  • Definiáljon egy kapacitásmodellt az alkalmazáshoz, amely tájékoztatja a számítási és tárolási erőforrások követelményeit az adatplatformon belül.

Gyorsítótárazás a gyakori elérésű réteg adataihoz

A memóriabeli gyorsítótárazási réteget az adatplatform javítására lehet alkalmazni az olvasási sebesség jelentős növelésével és a gyakori rétegbeli adatforgatókönyvek végpontok közötti ügyfél válaszidejének javításával.

Az Azure számos olyan szolgáltatást biztosít, amely alkalmazható képességekkel rendelkezik a kulcs adatstruktúrák gyorsítótárazásához, és Azure Cache for Redis az adatplatform olvasási hozzáférésének absztrakciója és optimalizálása céljából van elhelyezve. Ez a szakasz ezért az Azure Cache for Redis optimális használatára összpontosít olyan esetekben, amikor további olvasási teljesítményre és adathozzáférés tartósságára van szükség.

Kialakítási szempontok

  • A gyorsítótárazási réteg további adathozzáférési tartósságot biztosít, mivel még ha a mögöttes adattechnológiát érintő szolgáltatáskimaradás is hatással van rá, az alkalmazásadatok pillanatképe továbbra is elérhető a gyorsítótárazási rétegen keresztül.

  • Bizonyos számítási feladatok esetében a memóriabeli gyorsítótárazás az alkalmazásplatformon belül valósítható meg.

Azure Cache for Redis

  • A Redis Cache egy nyílt forráskód NoSQL-kulcs-érték memóriabeli tárolórendszer.

  • A nagyvállalati és nagyvállalati Flash-szintek egy aktív-aktív konfigurációban helyezhetők üzembe egy régión belül Availability Zones és különböző Azure-régiókban georeplikációval.

    • Ha az üzembe helyezés minden régióban legalább három Azure-régióban és három vagy több Availability Zones történik, és az aktív georeplikáció engedélyezve van az összes gyorsítótárpéldányon, Azure Cache for Redis 99,999%-os SLA-t biztosít egy regionális gyorsítótárvégponthoz való csatlakozáshoz.
    • Ha egyetlen Azure-régión belül három Availability Zones helyez üzembe, a rendszer 99,99%-os kapcsolati SLA-t biztosít.

  • Az Enterprise Flash szint RAM és flash nem felejtő memóriatárolók kombinációján fut, és bár ez egy kis teljesítménybeli büntetést vezet be, nagyon nagy gyorsítótárméreteket is lehetővé tesz, akár 13 TB-os fürtözést is.

  • A georeplikáció esetén a régiók közötti adatátvitel díjai a gyorsítótárpéldányokhoz kapcsolódó közvetlen költségek mellett is érvényesek lesznek.

  • Az Ütemezett Frissítések szolgáltatás nem tartalmazza az alapul szolgáló virtuális gép operációs rendszerére alkalmazott Azure-frissítéseket vagy -frissítéseket.

  • A felskálázási művelet során megnő a processzorkihasználtság, miközben az adatok új példányokra lesznek migrálva.

Tervezési javaslatok

  • Fontolja meg egy optimalizált gyorsítótárazási réteget a gyakori elérésű adatforgatókönyvekhez az olvasási sebesség növelése és a válaszidő javítása érdekében.

  • A gyorsítótár lejáratához és a takarításhoz megfelelő szabályzatokat alkalmazhat az elszabadult adatok növekedésének elkerülése érdekében.

    • Fontolja meg a gyorsítótárelemek lejáratát, amikor a háttéradatok megváltoznak.

Azure Cache for Redis

  • A prémium vagy nagyvállalati termékváltozat használatával maximalizálhatja a megbízhatóságot és a teljesítményt.

    • A rendkívül nagy adatkötetekkel rendelkező forgatókönyvek esetében a Nagyvállalati Flash-szintet kell figyelembe venni.
    • Olyan forgatókönyvek esetén, ahol csak passzív georeplikációra van szükség, a Prémium szint is megfontolható.

  • Replikapéldányok üzembe helyezése georeplikációval aktív konfigurációban az összes figyelembe vett üzembe helyezési régióban.

  • Győződjön meg arról, hogy a replikapéldányok Availability Zones vannak üzembe helyezve az egyes azure-régiókon belül.

  • Az Azure Monitor használatával kiértékelheti Azure Cache for Redis.

    • A regionális gyorsítótár-összetevők állapotpontszámának kiszámítása az üzleti követelményekhez és az erőforrás-kihasználtsághoz viszonyított állapot megfigyeléséhez.
    • Figyelje meg és figyelje meg a fontos metrikákat, például a magas processzorhasználatot, a magas memóriahasználatot, a magas kiszolgálóterhelést és a kiürített kulcsokat a gyorsítótár skálázásához szükséges megállapításokhoz.

  • Optimalizálja a kapcsolat rugalmasságát az újrapróbálkozási logika, az időtúllépések és a Redis-kapcsolat multiplexer egyszeri implementációjának alkalmazásával.

  • Konfigurálja az ütemezett frissítéseket a Redis Server-frissítések gyorsítótárra való alkalmazásának napjainak és időpontjának előírásához.

Elemzési forgatókönyvek

A kritikus fontosságú alkalmazások esetében egyre gyakoribb, hogy az elemzési forgatókönyveket az átfoglalt adatfolyamok további értékének hajtóeszközeként tekintik. Az alkalmazás- és működési (AIOps-) elemzési forgatókönyvek ezért a rendkívül megbízható adatplatform kritikus részét képezik.

Az elemzési és tranzakciós számítási feladatok különböző adatplatform-képességeket és optimalizálást igényelnek a megfelelő környezetekben az elfogadható teljesítmény érdekében.

Description Analitikai Tranzakcióalapú
Használati eset Nagyon nagy mennyiségű adat ("big data") elemzése Nagyon nagy mennyiségű egyedi tranzakció feldolgozása
Optimalizálva a következőre: Lekérdezések és összesítések olvasása több rekordon keresztül Közel valós idejű létrehozási/olvasási/frissítési/törlési (CRUD) lekérdezések néhány rekordon keresztül
Főbb jellemzők – Összesítés rekord adatforrásaiból
– Oszlopalapú tárolás
– Elosztott tároló
- Párhuzamos feldolgozás
- Denormalizált
– Alacsony egyidejűségi olvasások és írások
– Optimalizálás tömörítéssel rendelkező tárolókötethez		 – Az alkalmazás rekordjának adatforrása
- Soralapú tárolás
- Folytonos tárolás
- Szimmetrikus feldolgozás
-Normalizált
– Magas egyidejűségi olvasások és írások, indexfrissítések
– Optimalizálás gyors adathozzáféréshez memóriabeli tárterülettel

Azure Synapse egy nagyvállalati elemzési platformot biztosít, amely a relációs és nem relációs adatokat a Spark-technológiákkal egyesíti, és beépített integrációt használ az Azure-szolgáltatásokkal, például az Azure Cosmos DB-vel a big data-elemzés megkönnyítése érdekében. Az ebben a szakaszban szereplő tervezési szempontok és javaslatok ezért az elemzési forgatókönyvek optimális Azure Synapse és Azure Cosmos DB-használatára összpontosítanak.

Kialakítási szempontok

  • A nagy léptékű elemzési forgatókönyvek hagyományosan azáltal könnyítik meg az adatok kinyerését egy külön adatplatformba, amely a későbbi elemzési lekérdezésekre van optimalizálva.
    • A kinyerési, átalakítási és betöltési (ETL-) folyamatok az adatok kinyerésére szolgálnak, amelyek az átviteli sebességet használják fel, és hatással vannak a tranzakciós számítási feladatok teljesítményére.
    • Az ETL-folyamatok ritkán történő futtatása az átviteli sebesség és a teljesítmény hatásainak csökkentése érdekében kevésbé naprakész elemzési adatokat eredményez.
    • Az ETL-folyamatok fejlesztésének és karbantartásának többletterhelése az adatátalakítások összetettebbé válásával nő.
      • Ha például a forrásadatokat gyakran módosítják vagy törlik, az ETL-folyamatoknak az elemzési lekérdezések céladataiban bekövetkező változásokat additív/verziószámozott megközelítéssel, memóriaképekkel és újrabetöltéssel, illetve az elemzési adatok helyben végzett módosításaival kell figyelembe vennie. Ezen megközelítések mindegyike származékos hatással lesz, például indexek újralétrehozása vagy frissítése.

Azure Cosmos DB

  • Az Azure Cosmos DB tranzakciós adatain futtatott elemzési lekérdezések általában nagy mennyiségű adat partícióiban összesülnek, jelentős kérelemegység-átviteli sebességet használva, ami hatással lehet a környező tranzakciós számítási feladatok teljesítményére.

  • Az Azure Cosmos DB elemzési tár egy sémaalapú, teljesen izolált oszloporientált adattárat biztosít, amely lehetővé teszi az Azure Cosmos DB-adatok nagy léptékű elemzését Azure Synapse anélkül, hogy ez hatással lenne az Azure Cosmos DB tranzakciós számítási feladataira.

    • Ha egy Azure Cosmos DB-tároló elemzési tárként van engedélyezve, a rendszer belsőleg létrehoz egy új oszloptárolót a tároló műveleti adataiból. Ez az oszloptároló a tároló sororientált tranzakciótárolójától elkülönítve marad.
    • Az operatív adatok létrehozási, frissítési és törlési műveletei automatikusan szinkronizálódnak az elemzési tárba, így nincs szükség változáscsatornára vagy ETL-feldolgozásra.
    • Az üzemeltetésből az elemzési tárba irányuló adatszinkronizálás nem használja fel a tárolón vagy adatbázison kiosztott átviteli sebességet kérési egységeket (RU-kat). A tranzakciós számítási feladatokra nincs hatással a teljesítmény. Az elemzési tár nem igényel további kérelemegységek lefoglalását egy Azure Cosmos DB-adatbázison vagy -tárolón.
    • Az automatikus szinkronizálás az a folyamat, amelyben a működési adatok módosításai automatikusan szinkronizálódnak az elemzési tárba. Az automatikus szinkronizálás késése általában két (2) percnél rövidebb.
      • Az automatikus szinkronizálás késése akár öt (5) perc is lehet a megosztott átviteli sebességgel és nagy számú tárolóval rendelkező adatbázisok esetében.
      • Amint az automatikus szinkronizálás befejeződik, a legújabb adatok lekérdezhetők Azure Synapse.
    • Az Elemzési tár tár egy használatalapú díjszabási modellt használ, amely az adatok mennyiségéért, valamint az olvasási és írási műveletek számáért díjat számít fel. Az elemzési tár díjszabása eltér a tranzakciós áruház díjszabásától.

  • A Azure Synapse Link használatával az Azure Cosmos DB elemzési tár közvetlenül a Azure Synapse kérdezhető le. Ez lehetővé teszi az ETL nélküli, hibrid Transactional-Analytical-feldolgozást (HTAP) a Synapse-ből, hogy az Azure Cosmos DB-adatok közel valós időben lekérdezhetők legyenek a Synapse más elemzési számítási feladataival együtt.

  • Az Azure Cosmos DB elemzési tára alapértelmezés szerint nincs particionálva.

    • Bizonyos lekérdezési forgatókönyvek esetében a teljesítmény javulni fog az elemzési tár adatainak lekérdezési predikátumokban gyakran használt kulcsok használatával történő particionálásával .
    • A particionálást egy Azure Synapse feladat aktiválja, amely egy Spark-jegyzetfüzetet futtat a Synapse Link használatával, amely betölti az adatokat az Azure Cosmos DB elemzési tárából, és beírja azokat a Synapse-munkaterület elsődleges tárfiókjában lévő Synapse particionált tárolóba.

  • Azure Synapse Analytics kiszolgáló nélküli SQL-készletei automatikusan frissített nézeteken vagy parancsokon keresztül SELECT / OPENROWSET kérdezhetik le az elemzési tárat.

  • Azure Synapse Analytics Spark-készletek automatikusan frissített Spark-táblákon vagy a parancson keresztül kérdezhetik le az elemzési táratspark.read.

  • Az Adatok az Azure Cosmos DB elemzési tárból egy dedikált Synapse SQL-készletbe is másolhatók a Spark használatával, így a kiépített Azure Synapse SQL-készlet erőforrásai használhatók.

  • Az Azure Cosmos DB elemzési tár adatai lekérdezhetők Azure Synapse Sparkkal.

    • A Spark-jegyzetfüzetek lehetővé teszik a Spark-adatkeret-kombinációk számára az Azure Cosmos DB elemzési adatainak más adatkészletekkel való összesítését és átalakítását, valamint egyéb fejlett Synapse Spark-funkciók használatát, beleértve az átalakított adatok más tárolókba való írását vagy az AIOps Machine Learning-modellek betanítását.

Azure Cosmos DB elemzési oszloptároló

Azure Synapse

  • Azure Synapse egyesíti az elemzési képességeket, beleértve az SQL-adattárházakat, a Spark big data-t és a napló- és idősorozat-elemzések Data Explorer.

    • Azure Synapse társított szolgáltatásokat használ más szolgáltatásokhoz, például az Azure Storage-hoz való kapcsolatok meghatározásához.
    • Az adatok a támogatott forrásokból származó Copy tevékenység keresztül betölthetők a Synapse Analyticsbe. Ez lehetővé teszi az adatelemzést a Synapse-ben anélkül, hogy ez hatással lenne a forrásadattárra, de időt, költséget és késést eredményez az adatátvitel miatt.
    • Az adatok helyben is lekérdezhetők a támogatott külső tárolókban, elkerülve az adatbetöltés és -áthelyezés többletterhelését. A Data Lake Gen2-vel rendelkező Azure Storage a Synapse támogatott tárolója, és a Log Analytics exportált adatai a Synapse Sparkon keresztül kérdezhetők le.

  • Azure Synapse Studio egyesíti a betöltési és lekérdezési feladatokat.

    • A forrásadatok, beleértve az Azure Cosmos DB elemzési tár adatait és a Log Analytics exportálási adatait, lekérdezhetők és feldolgozhatók az üzleti intelligencia és más összesített elemzési használati esetek támogatása érdekében.

Azure Synapse Analytics

Tervezési javaslatok

  • Győződjön meg arról, hogy az elemzési számítási feladatok nem befolyásolják a tranzakciós alkalmazások számítási feladatait a tranzakciós teljesítmény fenntartása érdekében.

Application Analytics

AIOps és Operational Analytics

  • Hozzon létre egyetlen Azure Synapse munkaterületet társított szolgáltatásokkal és adatkészletekkel minden olyan forrás Azure Storage-fiókhoz, amelybe az erőforrásokból származó operatív adatok lesznek elküldve.

  • Hozzon létre egy dedikált Azure Storage-fiókot, és használja a munkaterület elsődleges tárfiókjaként a Synapse-munkaterület katalógusadatainak és metaadatainak tárolásához. Konfigurálja hierarchikus névtérrel az Azure Data Lake Gen2 engedélyezéséhez.

    • A forráselemzési adatok és a Synapse-munkaterület adatai és metaadatai közötti elkülönítés fenntartása.
      • Ne használjon olyan regionális vagy globális Azure Storage-fiókokat, ahol a működési adatok el lesznek küldve.

Következő lépés

Tekintse át a hálózatkezelési szempontokat.

Hálózat és kapcsolat