Gyorsítótárazási szabályzat (gyakori és ritka elérésű gyorsítótár)
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 creationTime
haszná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
, éshotcache
. - 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 éshotcache
a.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
= 56dhot 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
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: