Gyorsítótárazási szabályzat (gyakori és ritka elérésű gyorsítótár)

  • Cikk

Az Azure Data Explorer többrétegű adatgyorsítótár-rendszert használ a gyors lekérdezési teljesítmény biztosításához. Az adatok tárolása megbízható tárolóban történik, például Azure Blob Storage, de egyes részei gyorsítótárazva vannak a feldolgozási csomópontokon, az SSD-n vagy akár a RAM-ban a gyorsabb hozzáférés érdekében.

Real-Time Analytics többrétegű adatgyorsítótár-rendszert használ a gyors lekérdezési teljesítmény biztosításához. Az adatok tárolása megbízható tárolóban történik, például a OneLake-ben, de egyes részei gyorsítótárazva vannak a feldolgozási csomópontokon, az SSD-n vagy akár a RAM-ban a gyorsabb hozzáférés érdekében.

A gyorsítótárazási szabályzat lehetővé teszi, hogy eldöntse, mely adatokat kell gyorsítótárazza. A gyakori elérésű adatok gyorsítótárazása és a ritka elérésű adatgyorsítótár közötti különbséget úgy teheti meg, ha gyorsítótárazási szabályzatot állít be a gyakori elérésű adatokhoz. A gyakori elérésű adatokat a helyi SSD-tároló tárolja a gyorsabb lekérdezési teljesítmény érdekében, míg a ritka elérésű adatokat megbízható tárolóban tárolják, ami olcsóbb, de lassabban érhető el.

A gyorsítótár a helyi SSD-lemez 95%-át használja a gyakori elérésű adatokhoz. Ha nincs elegendő hely, a rendszer a legutóbbi adatokat kedvezményesen tárolja a gyorsítótárban. A fennmaradó 5%-ot olyan adatokhoz használjuk, amelyek nem minősülnek gyakori elérésűnek. Ez a kialakítás biztosítja, hogy a sok hideg adatot betöltő lekérdezések ne távolítják el a gyakori elérésű adatokat a gyorsítótárból.

A legjobb lekérdezési teljesítmény akkor érhető el, ha az összes betöltött adat gyorsítótárazva van. Előfordulhat azonban, hogy bizonyos adatok nem indokolják a gyakori elérésű gyorsítótárban való megőrzés költségeit. Előfordulhat például, hogy a ritkán elért régi naplórekordok kevésbé kritikus fontosságúak. Ilyen esetekben a csapatok gyakran alacsonyabb lekérdezési teljesítményt választanak, mint a fizetést, hogy az adatok melegen maradjanak.

A felügyeleti parancsokkal módosíthatja a gyorsítótárazási szabályzatot az adatbázis, a tábla vagy a materializált nézet szintjén.

A felügyeleti parancsokkal módosíthatja a gyorsítótárazási szabályzatot a fürt, az adatbázis, a tábla vagy a materializált nézet szintjén.

Tipp

A fürt olyan alkalmi lekérdezésekhez készült, amelyek köztes eredményhalmazokkal rendelkeznek, amelyek illeszkednek a fürt teljes RAM-jában. A nagy feladatok, például a térkép-csökkentés esetében hasznos lehet a köztes eredmények állandó tárolóban való tárolása. Ehhez hozzon létre egy folyamatos exportálási feladatot. Ez a funkció lehetővé teszi a hosszú ideig futó kötegelt lekérdezések végrehajtását olyan szolgáltatások használatával, mint a HDInsight vagy az Azure Databricks.

Gyorsítótárazási szabályzat alkalmazása

Az adatok betöltésekor a rendszer nyomon követi a betöltés dátumát és időpontját, valamint a létrehozott mértéket. A gyorsítótárazási szabályzat kiértékeléséhez a mérték betöltési dátumának és időértékének (vagy a maximális értéknek, ha egy mérték több, már meglévő mértékből lett létrehozva) kiértékelésére szolgál.

Megjegyzés

A betöltési dátum és idő értékét a betöltési tulajdonság creationTimehasználatával adhatja meg. Ha így tesz, győződjön meg arról, hogy a Lookback tábla hatályos Extents merge szabályzatának tulajdonsága igazodik a megadott értékekhez creationTime.

Alapértelmezés szerint a hatályos szabályzat a null, ami azt jelenti, hogy az összes adat gyakori elérésűnek minősül. A null táblaszintű szabályzatok azt jelentik, hogy a szabályzat öröklődik az adatbázisból. A nemnull táblaszintű szabályzatok felülbírálják az adatbázisszintű szabályzatokat.

Hatókörkezelési lekérdezések gyorsgyorsítótárba

Lekérdezések futtatásakor a hatókört korlátozhatja arra, hogy csak a gyorsgyorsítótárban lévő adatokat kérdezhesse le.

Megjegyzés

Az adatok hatókörkezelése csak a gyorsítótárazási szabályzatokat támogató entitásokra vonatkozik, például táblákra és materializált nézetekre. A rendszer figyelmen kívül hagyja más entitások, például külső táblák és a sortárolóban lévő adatok esetében.

Több lekérdezési lehetőség is rendelkezésre áll:

  • Adjon hozzá egy nevű query_datascope ügyfélkérési tulajdonságot a lekérdezéshez. Lehetséges értékek: default, all, és hotcache.
  • Használjon utasítást set a lekérdezés szövegében: set query_datascope='...'. A lehetséges értékek megegyeznek az ügyfélkérés tulajdonságával.
  • Adjon hozzá egy datascope=... szöveget közvetlenül a táblahivatkozás után a lekérdezés törzsében. A lehetséges értékek a és hotcachea.all

Az default érték a fürt alapértelmezett beállításainak használatát jelzi, amelyek meghatározzák, hogy a lekérdezésnek az összes adatot tartalmaznia kell.

Ha eltérés van a különböző metódusok között, akkor set elsőbbséget élvez az ügyfélkérés tulajdonságával szemben. A táblahivatkozások értékének megadása mindkettővel szemben elsőbbséget élvez.

Az alábbi lekérdezésben például az összes táblahivatkozás csak a gyorsgyorsítótár-adatokat használja, kivéve a "T" második hivatkozását, amely az összes adatra kiterjed:

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

Gyorsítótárazási szabályzat és adatmegőrzési szabályzat

A gyorsítótárazási szabályzat független a megőrzési szabályzattól:

  • A gyorsítótárazási szabályzat határozza meg az erőforrások rangsorolását. A fontos adatok lekérdezései gyorsabbak.
  • Az adatmegőrzési szabályzat határozza meg a táblában/adatbázisban található lekérdezhető adatok mértékét (konkrétan). SoftDeletePeriod

Konfigurálja ezt a szabályzatot úgy, hogy a várt lekérdezési minta alapján optimális egyensúlyt érjen el a költségek és a teljesítmény között.

Példa:

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

A példában az utolsó 28 nap adatai a fürt SSD-jén lesznek, a további 28 napnyi adat pedig az Azure Blob Storage-ban lesz tárolva. A lekérdezéseket a teljes 56 napon belül futtathatja.

Kapcsolódó tartalom