Zwischenspeicherungsrichtlinie (heißer und kalter Cache)

  • Artikel

Azure Data Explorer verwendet ein Datencachesystem mit mehreren Ebenen, um eine schnelle Abfrageleistung sicherzustellen. Daten werden in zuverlässigem Speicher gespeichert, z. B. Azure Blob Storage, aber Teile davon werden auf Verarbeitungsknoten, SSD oder sogar im RAM zwischengespeichert, um den Zugriff zu beschleunigen.

Real-Time Analytics verwendet ein Datencachesystem mit mehreren Ebenen, um eine schnelle Abfrageleistung zu gewährleisten. Daten werden in zuverlässigem Speicher wie OneLake gespeichert, aber Teile davon werden auf Verarbeitungsknoten, SSD oder sogar im RAM zwischengespeichert, um den Zugriff zu beschleunigen.

Mit der Zwischenspeicherungsrichtlinie können Sie auswählen, welche Daten zwischengespeichert werden sollen. Sie können zwischen heißem Datencache und kaltem Datencache unterscheiden, indem Sie eine Zwischenspeicherungsrichtlinie für heiße Daten festlegen. Heiße Daten werden im lokalen SSD-Speicher gespeichert, um die Abfrageleistung zu beschleunigen, während kalte Daten in zuverlässigem Speicher gespeichert werden, der billiger, aber langsamer zugänglich ist.

Der Cache verwendet 95 % des lokalen SSD-Datenträgers für heiße Daten. Wenn nicht genügend Speicherplatz vorhanden ist, werden die neuesten Daten bevorzugt im Cache gespeichert. Die verbleibenden 5 % werden für Daten verwendet, die nicht als heiß kategorisiert werden. Dieser Entwurf stellt sicher, dass Abfragen, die viele kalte Daten laden, keine heißen Daten aus dem Cache entfernen.

Die beste Abfrageleistung wird erreicht, wenn alle erfassten Daten zwischengespeichert werden. Bestimmte Daten können jedoch nicht den Aufwand dafür rechtfertigen, im heißen Cache gespeichert zu werden. Für instance können selten verwendete alte Protokolldatensätze als weniger wichtig angesehen werden. In solchen Fällen entscheiden sich Teams häufig für eine niedrigere Abfrageleistung als für die Bezahlung, um die Daten warm zu halten.

Verwenden Sie Verwaltungsbefehle, um die Zwischenspeicherungsrichtlinie auf Datenbank-, Tabellen- oder materialisierter Sichtebene zu ändern.

Verwenden Sie Verwaltungsbefehle, um die Zwischenspeicherungsrichtlinie auf Cluster-, Datenbank-, Tabellen- oder materialisierter Sichtebene zu ändern.

Tipp

Ihr Cluster ist für Ad-hoc-Abfragen mit zwischengeschalteten Resultsets konzipiert, die in den Gesamten RAM des Clusters passen. Bei großen Aufträgen, z. B. map-reduce, kann es hilfreich sein, Zwischenergebnisse in persistentem Speicher zu speichern. Erstellen Sie hierzu einen Auftrag für den fortlaufenden Export . Mit diesem Feature können Sie Batchabfragen mit langer Ausführungszeit mithilfe von Diensten wie HDInsight oder Azure Databricks durchführen.

Anwendung der Zwischenspeicherungsrichtlinie

Wenn Daten erfasst werden, verfolgt das System das Datum und die Uhrzeit der Erfassung sowie den umfang, der erstellt wurde. Der Erfassungsdatums- und Uhrzeitwert des Blöckes (oder der Höchstwert, wenn ein Bereich aus mehreren bereits vorhandenen Blöcken erstellt wurde) wird verwendet, um die Zwischenspeicherungsrichtlinie auszuwerten.

Hinweis

Sie können einen Wert für das Erfassungsdatum und die Erfassungszeit angeben, indem Sie die Erfassungseigenschaft verwenden creationTime. Stellen Sie dabei sicher, dass die Lookback Eigenschaft in der effektiven Richtlinie für die Zusammenführung von Blöcken der Tabelle mit den Werten übereinstimmt, die Sie für festgelegt haben creationTime.

Standardmäßig ist nulldie effektive Richtlinie . Dies bedeutet, dass alle Daten als heiß angesehen werden. Eine null Richtlinie auf Tabellenebene bedeutet, dass die Richtlinie von der Datenbank geerbt wird. Eine Richtlinie auf Nicht-Tabellenebenenull überschreibt eine Richtlinie auf Datenbankebene.

Eingrenzen von Abfragen in hot cache

Beim Ausführen von Abfragen können Sie den Bereich auf abfragende Daten im heißen Cache beschränken.

Hinweis

Der Datenbereich gilt nur für Entitäten, die Zwischenspeicherungsrichtlinien unterstützen, z. B. Tabellen und materialisierte Sichten. Sie wird für andere Entitäten ignoriert, z. B. externe Tabellen und Daten im Zeilenspeicher.

Es gibt mehrere Abfragemöglichkeiten:

  • Fügen Sie der Abfrage eine Clientanforderungseigenschaft hinzu, die aufgerufen wird query_datascope . Mögliche Werte: default, all und hotcache.
  • Verwenden Sie eine set -Anweisung im Abfragetext: set query_datascope='...'. Mögliche Werte sind identisch mit denen für die Clientanforderungseigenschaft.
  • Fügen Sie unmittelbar nach einem Tabellenverweis im Abfragetext einen datascope=... Text hinzu. Mögliche Werte sind all und hotcache.

Der default Wert gibt die Verwendung der Standardeinstellungen des Clusters an, die festlegen, dass die Abfrage alle Daten abdecken soll.

Wenn eine Diskrepanz zwischen den verschiedenen Methoden besteht, set hat Vorrang vor der Clientanforderungseigenschaft. Die Angabe eines Werts für einen Tabellenverweis hat Vorrang vor beiden.

In der folgenden Abfrage verwenden z. B. alle Tabellenverweise nur hot cache-Daten, mit Ausnahme des zweiten Verweises auf "T", der auf alle Daten ausgerichtet ist:

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

Zwischenspeicherungsrichtlinie und Aufbewahrungsrichtlinie

Die Zwischenspeicherungsrichtlinie ist unabhängig von der Aufbewahrungsrichtlinie:

  • Die Zwischenspeicherungsrichtlinie definiert, wie Ressourcen priorisiert werden. Abfragen für wichtige Daten sind schneller.
  • Die Aufbewahrungsrichtlinie definiert den Umfang der abfragbaren Daten in einer Tabelle/Datenbank (insbesondere SoftDeletePeriod).

Konfigurieren Sie diese Richtlinie, um basierend auf dem erwarteten Abfragemuster ein optimales Gleichgewicht zwischen Kosten und Leistung zu erzielen.

Beispiel:

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

Im Beispiel befinden sich die Daten der letzten 28 Tage auf der Cluster-SSD, und die zusätzlichen 28 Tage der Daten werden in Azure Blob Storage gespeichert. Sie können Abfragen für die gesamten 56 Tage der Daten ausführen.

Verwandte Inhalte