Integrált Azure Cosmos DB-gyorsítótár – Áttekintés

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az Azure Cosmos DB integrált gyorsítótára egy memóriabeli gyorsítótár, amely segít a kezelhető költségek és az alacsony késés biztosításában a kérések mennyiségének növekedésével. Az integrált gyorsítótár egyszerűen beállítható, és nem kell egyéni kódot írnia a gyorsítótár érvénytelenítéséhez vagy a háttérinfrastruktúra kezeléséhez. Az integrált gyorsítótár a dedikált átjárót használja az Azure Cosmos DB-fiókban. A dedikált átjáró kiépítésekor a számítási feladathoz szükséges magok és memória alapján kiválaszthatja a csomópontok számát és a csomópont méretét. Minden dedikált átjárócsomópont külön integrált gyorsítótárral rendelkezik a többitől.

A rendszer automatikusan konfigurál egy integrált gyorsítótárat a dedikált átjárón belül. Az integrált gyorsítótár két részből áll:

• Elemgyorsítótár pontolvasásokhoz
• Lekérdezések lekérdezési gyorsítótára

Az integrált gyorsítótár egy átolvasott, írási gyorsítótár, amely egy legkevésbé használt (LRU) kiürítési szabályzattal rendelkezik. Az elemgyorsítótár és a lekérdezésgyorsítótár ugyanazzal a kapacitással rendelkezik az integrált gyorsítótáron belül, és az LRU kizárási szabályzata mindkettőre érvényes. A rendszer szigorúan attól függően távolítja el az adatokat a gyorsítótárból, hogy mikor használták legutóbb, függetlenül attól, hogy pontolvasásról vagy lekérdezésről van-e szó. Az egyes csomópontokon belüli gyorsítótárazott adatok az adott csomóponton nemrég írt vagy beolvasott adatoktól függenek. Ha egy elem vagy lekérdezés gyorsítótárazva van az egyik csomóponton, akkor az nem feltétlenül gyorsítótárazva van a többi csomóponton.

Az integrált gyorsítótár előnyeit élvező számítási feladatok

Az integrált gyorsítótár fő célja az írásvédett számítási feladatok költségeinek csökkentése. Az alacsony késés, bár hasznos, nem az integrált gyorsítótár fő előnye, mivel az Azure Cosmos DB gyorsítótárazás nélkül már gyors.

Az integrált gyorsítótárat elérő pontolvasások és lekérdezések 0 ru-díjjal rendelkeznek. A gyorsítótár-találatok műveletenkénti költségei sokkal alacsonyabbak, mint a háttéradatbázisból származó olvasások.

Az alábbi jellemzőknek megfelelő számítási feladatoknak ki kell értékelnie, hogy az integrált gyorsítótár segít-e a költségek csökkentésében:

• Írásvédett számítási feladatok
• Sok ismétlődő pont felolvassa a nagy elemeket
• Sok ismétlődő magas ru-lekérdezés
• Gyakori particionálási kulcs olvasásokhoz

A várható megtakarítások legnagyobb tényezője az, hogy az olvasások milyen mértékben ismétlődnek. Ha a számítási feladat rövid időn belül következetesen ugyanazt a pontolvasást vagy lekérdezést hajtja végre, az kiválóan alkalmas az integrált gyorsítótár használatára. Ha az integrált gyorsítótárat többszöri olvasáshoz használja, csak az első olvasáshoz használja a kérelemegységeket. A későbbi beolvasások ugyanazon a dedikált átjárócsomóponton (az MaxIntegratedCacheStaleness ablakban, és ha az adatok nem lettek kiürítve) nem használnak átviteli sebességet.

Egyes számítási feladatok nem veszik figyelembe az integrált gyorsítótárat, például:

• Írási terhelésű számítási feladatok
• Ritkán ismétlődő pontolvasások vagy lekérdezések
• A változáscsatornát olvasó számítási feladatok

Elemgyorsítótár

Az elemgyorsítótár pontolvasásokhoz használható (a kulcs/érték keresése az elemazonosító és a partíciókulcs alapján).

Az elemgyorsítótár feltöltése

• A rendszer automatikusan feltölti az új írásokat, frissítéseket és törléseket annak a csomópontnak az elemgyorsítótárában, amelyen a kérés át lesz irányítva
• Az olyan pontolvasási kérelmekből származó elemek, amelyeknél az elem még nem szerepel a csomópont gyorsítótárában (a gyorsítótár hiányzik), a rendszer hozzáadja a kérést az elemgyorsítótárhoz
• Több elem( például a ReadMany) olvasási kérései az elemgyorsítótár helyett készletként töltik fel a lekérdezési gyorsítótárat egyéni elemként
• A tranzakciós köteg részét képező vagy tömeges módban lévő kérések nem töltik fel az elemgyorsítótárat

Elemgyorsítótár érvénytelenítése és kiürítése

Mivel minden csomópont rendelkezik független gyorsítótárral, lehetséges, hogy az elemeket az egyik csomópont gyorsítótára érvényteleníti vagy kiüríti, a többit nem. Az adott csomópont gyorsítótárában lévő elemek érvénytelenítve és kiürítve lesznek az alábbi feltételek alapján:

• Elem frissítése vagy törlése
• Legutóbb használt (LRU)
• Gyorsítótár megőrzési ideje (más szóval a MaxIntegratedCacheStaleness)

Lekérdezési gyorsítótár

A lekérdezésgyorsítótár a lekérdezések gyorsítótárazására szolgál. A lekérdezési gyorsítótár kulcs-/értékkereséssé alakítja át a lekérdezést, ahol a kulcs a lekérdezés szövege, az érték pedig a lekérdezés eredménye. Az integrált gyorsítótár nem rendelkezik lekérdezési motorral, csak az egyes lekérdezések kulcs-érték keresését tárolja. A lekérdezési eredmények készletként vannak tárolva, és a gyorsítótár nem követi nyomon az egyes elemeket. Egy adott elem többször is tárolható a lekérdezési gyorsítótárban, ha több lekérdezés eredményhalmazában jelenik meg. A mögöttes elemek frissítései csak akkor jelennek meg a lekérdezés eredményeiben, ha eléri a lekérdezés integrált gyorsítótárának maximális elavultságát , és a lekérdezés a háttéradatbázisból lesz kézbesítve.

A lekérdezési gyorsítótár feltöltése

• Ha a gyorsítótárnak nincs eredménye a lekérdezéshez (a gyorsítótár hiányzik) azon a csomóponton, amelyen át lett irányítva, a rendszer elküldi a lekérdezést a háttérrendszernek. A lekérdezés futtatása után a gyorsítótár tárolja a lekérdezés eredményeit
• Az eredményeket befolyásoló különböző paraméterekkel vagy kérési beállításokkal (ex. max elemszámmal) rendelkező lekérdezések saját kulcs/érték párként vannak tárolva
• Több elem( például a ReadMany) kéréseinek olvasása feltölti a lekérdezési gyorsítótárat. A ReadMany-eredmények készletként vannak tárolva, és a különböző bemenetekkel rendelkező kérések saját kulcs/érték párként lesznek tárolva

Lekérdezésgyorsítótár kiürítése

A lekérdezési gyorsítótár kiürítése azon a csomóponton alapul, amelyen a kérést átirányították. Lehetséges, hogy a lekérdezések nem az egyik csomóponton, hanem az egyik csomóponton törölhetők vagy frissíthetők.

• Legutóbb használt (LRU)
• Gyorsítótár megőrzési ideje (más szóval a MaxIntegratedCacheStaleness)

A lekérdezési gyorsítótár használata

A lekérdezési gyorsítótár használatakor nincs szükség speciális kódra, még akkor sem, ha a lekérdezések több oldalnyi eredménnyel rendelkeznek. A lekérdezések lapozásának ajánlott eljárásai és kódja megegyezik attól, hogy a lekérdezés eléri az integrált gyorsítótárat, vagy a háttérbeli lekérdezési motoron fut.

A lekérdezésgyorsítótár adott esetben automatikusan gyorsítótárazza a lekérdezés-folytatási jogkivonatokat. Ha többoldalas lekérdezéssel rendelkezik, az integrált gyorsítótárban tárolt lapok 0 RU-díjat számítanak fel. Ha a lekérdezési eredmények későbbi lapjai háttérbeli végrehajtást igényelnek, az előző oldalhoz tartozó folytatási jogkivonattal rendelkeznek, így elkerülhetik az előző munka duplikálását.

Integrált gyorsítótár-konzisztencia

Az integrált gyorsítótár csak munkamenettel és végleges konzisztenciával támogatja az olvasási kéréseket. Ha egy olvasás konzisztens előtaggal, korlátozott elavultsággal vagy erős konzisztenciával rendelkezik, az áthalad az integrált gyorsítótáron, és a háttérrendszerből lesz kiszolgálva.

A legegyszerűbben úgy konfigurálhatja a munkamenetet vagy a végleges konzisztenciát az összes olvasáshoz, ha a fiók szintjén állítja be. Ha azonban csak bizonyos olvasások konzisztenciáját szeretné, konzisztenciát is konzisztenciát konfigurálhat a kérés szintjén.

Munkamenet-konzisztencia

A munkamenet-konzisztencia a legszélesebb körben használt konzisztenciaszint az egyetlen régióban és a globálisan elosztott Azure Cosmos DB-fiókokban. A munkamenet-konzisztenciával az egyetlen ügyfél-munkamenetek saját írásokat olvashatnak. Minden olyan munkamenetkonzisztenciával rendelkező olvasás, amely nem rendelkezik egyező munkamenet-jogkivonattal, ru-díjakat von maga után. Ez magában foglalja egy adott elem vagy lekérdezés első kérését az ügyfélalkalmazás indításakor vagy újraindításakor, kivéve, ha explicit módon ad át érvényes munkamenet-jogkivonatot. Az írást végző munkameneten kívüli ügyfelek végső konzisztenciát fognak látni az integrált gyorsítótár használatakor.

MaxIntegratedCacheStaleness

A MaxIntegratedCacheStaleness gyorsítótárazott pontolvasások és -lekérdezések maximálisan elfogadható elavultsága, függetlenül a kiválasztott konzisztenciatól. A MaxIntegratedCacheStaleness kérelemszinten konfigurálható. Ha például 2 órát állít be MaxIntegratedCacheStaleness , a kérés csak akkor ad vissza gyorsítótárazott adatokat, ha az adatok 2 óránál rövidebbek. Az integrált gyorsítótár használatával történő ismételt olvasások valószínűségének növelése érdekében az üzleti követelményeknek megfelelő értéket kell beállítania MaxIntegratedCacheStaleness .

Ha MaxIntegratedCacheStalenessolyan kérelemre van konfigurálva, amely végül feltölti a gyorsítótárat, az nem befolyásolja, hogy mennyi ideig legyen gyorsítótárazva a kérés. MaxIntegratedCacheStaleness konzisztenciát kényszerít a gyorsítótárazott adatok olvasásakor. Nincs globális TTL- vagy gyorsítótár-megőrzési beállítás, ezért az adatok csak akkor lesznek kiürítve a gyorsítótárból, ha az integrált gyorsítótár megtelt, vagy ha egy új olvasási funkció az aktuális gyorsítótárazott bejegyzés koránál alacsonyabb MaxIntegratedCacheStaleness életkorral fut.

Ez javulást jelent a legtöbb gyorsítótár működéséhez, és lehetővé teszi a következő testreszabásokat:

• Az egyes pontok olvasására vagy lekérdezésére különböző elavultsági követelményeket állíthat be
• A különböző ügyfelek akkor is konfigurálhatnak különböző MaxIntegratedCacheStaleness értékeket, ha ugyanazt a pontolvasást vagy lekérdezést futtatják
• Ha módosítani szeretné a gyorsítótárazott adatok olvasási konzisztenciáját, a módosítás MaxIntegratedCacheStaleness azonnali hatással van az olvasási konzisztenciára

A paraméter jobb megértéséhez MaxIntegratedCacheStaleness vegye figyelembe a következő példát:

A MaxIntegratedCacheStaleness/> konfigurálása

Az integrált gyorsítótár megkerülése

Az integrált gyorsítótár korlátozott tárolási kapacitással rendelkezik, amelyet a kiépített dedikált átjáró termékváltozata határoz meg. Alapértelmezés szerint a dedikált átjáróval konfigurált ügyfelektől érkező összes kérés kapcsolati sztring áthalad az integrált gyorsítótáron, és helyet foglal a gyorsítótárban. Az integrált gyorsítótárazási kérelem megkerülésével szabályozhatja, hogy mely elemek és lekérdezések legyenek gyorsítótárazva. Ez a kérési lehetőség olyan elemírási vagy olvasási kérelmek esetén hasznos, amelyek várhatóan nem ismétlődnek meg gyakran. Ha megkerüli az integrált gyorsítótárat a ritkán használt hozzáféréssel rendelkező elemekhez, a több ismétléssel rendelkező elemek gyorsítótárterületét takarítja meg, növeli a ru-mentési potenciált, és csökkenti a kiürítéseket. A gyorsítótárat megkerülő kérések továbbra is a dedikált átjárón keresztül lesznek irányítva. Ezek a kérések a háttérrendszerből és a költség-kérelemegységekből lesznek kézbesítve.

Ismerje meg az integrált gyorsítótár megkerülését.

Mérőszámok

Hasznos az integrált gyorsítótár néhány kulcsának DedicatedGateway és IntegratedCache metrikáinak monitorozása. Ezekről a metrikákról a Microsoft.DocumentDB/DatabaseAccounts támogatott metrikái című témakörben olvashat.

Alapértelmezés szerint minden meglévő metrika elérhető az Azure Portal metrikáiból (nem klasszikus metrikák):

A metrikák az összes dedikált átjárócsomópont átlagát, maximumát vagy összegét képezik. Ha például egy dedikált átjárófürtöt hoz létre öt csomóponttal, a metrikák mind az öt csomópont összesített értékét tükrözik. Nem lehet meghatározni az egyes csomópontok metrikaértékét.

Gyakori problémák megoldása

Az alábbi példák bemutatják, hogyan lehet hibakeresést végezni néhány gyakori forgatókönyvben:

Nem tudom megállapítani, hogy az alkalmazásom a dedikált átjárót használja-e

Ellenőrizze a DedicatedGatewayRequests. Ez a metrika tartalmazza a dedikált átjárót használó összes kérést, függetlenül attól, hogy az integrált gyorsítótárba ütköznek-e. Ha az alkalmazás a standard átjárót vagy a közvetlen módot használja az eredeti kapcsolati sztring, akkor nem jelenik meg hibaüzenet, de nulla DedicatedGatewayRequests lesz. Ha az alkalmazás közvetlen módot használ a dedikált átjáróval kapcsolati sztring, néhányat továbbra is láthatDedicatedGatewayRequests.

Nem tudom megállapítani, hogy a kéréseim elérik-e az integrált gyorsítótárat

Ellenőrizze az és IntegratedCacheQueryHitRatea IntegratedCacheItemHitRate . Ha mindkét érték nulla, akkor a kérések nem érik el az integrált gyorsítótárat. Ellenőrizze, hogy a dedikált átjárót kapcsolati sztring használja-e, csatlakozik-e átjáró módhoz, és munkamenetet vagy végleges konzisztenciát használ-e.

Meg akarom érteni, hogy a dedikált átjáróm túl kicsi-e

Ellenőrizze az és IntegratedCacheQueryHitRatea IntegratedCacheItemHitRate . A magas értékek (például 0,7-0,8 felett) jó jel arra, hogy a dedikált átjáró elég nagy.

Ha a IntegratedCacheItemHitRate vagy IntegratedCacheQueryHitRatealacsony, tekintse meg a IntegratedCacheEvictedEntriesSize. Ha magas IntegratedCacheEvictedEntriesSize , az azt jelentheti, hogy egy nagyobb dedikált átjáróméret előnyös lenne. Kísérletezhet a dedikált átjáró méretének növelésével és az új IntegratedCacheItemHitRate és IntegratedCacheQueryHitRatea . Ha egy nagyobb dedikált átjáró nem javítja a IntegratedCacheItemHitRate vagy IntegratedCacheQueryHitRate, lehetséges, hogy az olvasások egyszerűen nem ismétlődnek meg eléggé ahhoz, hogy az integrált gyorsítótár hatásosabb legyen.

Szeretném megtudni, hogy a dedikált átjáróm túl nagy-e

Nehezebb mérni, ha egy dedikált átjáró túl nagy, mint azt mérni, hogy egy dedikált átjáró túl kicsi-e. Általánosságban elmondható, hogy kis méretűre kell kezdenie, és lassan növelnie kell a dedikált átjáró méretét, amíg a IntegratedCacheItemHitRate IntegratedCacheQueryHitRate folyamat nem javul. Bizonyos esetekben a két gyorsítótár találati metrikája közül csak az egyik lesz fontos, nem mindkettő. Ha például a számítási feladat elsősorban lekérdezés, és nem pontolvasás, akkor sokkal IntegratedCacheQueryHitRate fontosabb, mint a IntegratedCacheItemHitRate.

Ha a legtöbb adatot az LRU túllépése MaxIntegratedCacheStalenessmiatt kiürítik a gyorsítótárból, a gyorsítótár a szükségesnél nagyobb lehet. Ha IntegratedCacheItemExpirationCount az összevonás majdnem IntegratedCacheQueryExpirationCount olyan nagy, mint IntegratedCacheEvictedEntriesSizeaz, kísérletezhet kisebb dedikált átjárómérettel, és összehasonlíthatja a teljesítményt.

Szeretném megtudni, hogy szükség van-e további dedikált átjárócsomópontok hozzáadására

Bizonyos esetekben, ha a késés váratlanul magas, előfordulhat, hogy nagyobb csomópontok helyett több dedikált átjárócsomópontra van szüksége. Ellenőrizze és DedicatedGatewayCPUUsage DedicatedGatewayMemoryUsage állapítsa meg, hogy a dedikáltabb átjárócsomópontok hozzáadása csökkenti-e a késést. Érdemes szem előtt tartani, hogy mivel az integrált gyorsítótár összes példánya független egymástól, a dedikáltabb átjárócsomópontok hozzáadása nem csökkenti a IntegratedCacheEvictedEntriesSize. Ha további csomópontokat ad hozzá, az javíthatja a dedikált átjárófürt által kezelhető kérelemkötetet.

Következő lépések

• Integrált gyorsítótár – gyakori kérdések
• Az integrált gyorsítótár konfigurálása
• Dedikált átjáró
• 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 annyit tud, hogy hány virtuális mag és kiszolgáló található a meglévő adatbázisfürtben, 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ővel