Dela via

Cachelagringsprincip (frekvent och kall cache)

  • Artikel

Azure Data Explorer använder ett datacachesystem med flera nivåer för att säkerställa snabba frågeprestanda. Data lagras i tillförlitlig lagring, till exempel Azure Blob Storage, men delar av dem cachelagras på bearbetningsnoder, SSD eller till och med i RAM-minne för snabbare åtkomst.

Real-Time Analytics använder ett datacachesystem med flera nivåer för att säkerställa snabba frågeprestanda. Data lagras i tillförlitlig lagring, till exempel OneLake, men delar av dem cachelagras på bearbetningsnoder, SSD eller till och med i RAM-minne för snabbare åtkomst.

Med cachelagringsprincipen kan du välja vilka data som ska cachelagras. Du kan skilja mellan frekvent datacache och kall datacache genom att ange en cachelagringsprincip för frekventa data. Frekventa data sparas i lokal SSD-lagring för snabbare frågeprestanda, medan kalldata lagras i tillförlitlig lagring, vilket är billigare men långsammare att komma åt.

Cachen använder 95 % av den lokala SSD-disken för frekventa data. Om det inte finns tillräckligt med utrymme behålls de senaste data företrädesvis i cacheminnet. De återstående 5 % används för data som inte kategoriseras som frekventa. Den här designen säkerställer att frågor som läser in många kalla data inte tar bort heta data från cachen.

Bästa frågeprestanda uppnås när alla inmatade data cachelagras. Vissa data kanske dock inte garanterar kostnaden för att förvaras i den frekventa cachen. Ofta använda gamla loggposter kan till exempel betraktas som mindre viktiga. I sådana fall väljer team ofta lägre frågeprestanda jämfört med att betala för att hålla data varma.

Använd hanteringskommandon för att ändra cachelagringsprincipen på databas-, tabell- eller materialiserad vynivå .

Använd hanteringskommandon för att ändra cachelagringsprincipen på kluster-, databas-, tabell- eller materialiserad visningsnivå .

Tips

Klustret är utformat för ad hoc-frågor med mellanliggande resultatuppsättningar som passar i klustrets totala RAM-minne. För stora jobb, till exempel map-reduce, kan det vara användbart att lagra mellanliggande resultat i beständig lagring. Det gör du genom att skapa ett jobb för kontinuerlig export . Med den här funktionen kan du köra tidskrävande batchfrågor med tjänster som HDInsight eller Azure Databricks.

Så tillämpas cachelagringsprincipen

När data matas in håller systemet reda på datum och tid för inmatningen och den omfattning som skapades. Inmatningens datum- och tidsvärde för omfattningen (eller det maximala värdet, om ett utrymme har skapats från flera befintliga utrymmen), används för att utvärdera cachelagringsprincipen.

Anteckning

Du kan ange ett värde för inmatningsdatum och -tid med hjälp av inmatningsegenskapen creationTime. När du gör det kontrollerar du att Lookback egenskapen i tabellens gällande sammanslagningsprincip för Utrymmen är justerad med de värden som du anger för creationTime.

Som standard är nullden effektiva principen , vilket innebär att alla data anses vara frekventa. En null princip på tabellnivå innebär att principen ärvs från databasen. En icke-tabellnivåprincipnull åsidosätter en princip på databasnivå.

Omfångsfrågor för frekvent cachelagring

När du kör frågor kan du begränsa omfånget till att endast fråga efter data i frekvent cache.

Anteckning

Dataomfånget gäller endast för entiteter som stöder cachelagringsprinciper, till exempel tabeller och materialiserade vyer. Den ignoreras för andra entiteter, till exempel externa tabeller och data i radlagret.

Det finns flera frågemöjligheter:

  • Lägg till en klientförfrågningsegenskap med namnet query_datascope i frågan. Möjliga värden: default, alloch hotcache.
  • Använd en set -instruktion i frågetexten: set query_datascope='...'. Möjliga värden är samma som för egenskapen för klientbegäran.
  • Lägg till en datascope=... text direkt efter en tabellreferens i frågetexten. Möjliga värden är all och hotcache.

Värdet default anger användningen av standardinställningarna för klustret, som avgör att frågan ska omfatta alla data.

Om det finns en avvikelse mellan de olika metoderna har du set företräde framför egenskapen för klientbegäran. Att ange ett värde för en tabellreferens har företräde framför båda.

I följande fråga använder till exempel alla tabellreferenser endast frekvent cachedata, förutom den andra referensen till "T", som är begränsad till alla data:

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

Cachelagringsprincip jämfört med kvarhållningsprincip

Cachelagringsprincipen är oberoende av kvarhållningsprincipen:

  • Cachelagringsprincipen definierar hur resurser ska prioriteras. Frågor för viktiga data går snabbare.
  • Kvarhållningsprincipen definierar omfattningen av frågebara data i en tabell/databas (specifikt SoftDeletePeriod).

Konfigurera den här principen för att uppnå optimal balans mellan kostnad och prestanda, baserat på det förväntade frågemönstret.

Exempel:

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

I exemplet finns de senaste 28 dagarnas data på klustrets SSD och de ytterligare 28 dagarnas data lagras i Azure Blob Storage. Du kan köra frågor för hela 56 dagars data.

Relaterat innehåll