Freigeben über


Cache-Richtlinie (Cache für heiße und kalte Daten)

Gilt für: ✅Microsoft Fabric✅Azure Data Explorer

Um eine schnelle Abfrageleistung sicherzustellen, wird ein mehrstufiges Datencachesystem verwendet. Daten werden im zuverlässigen Speicher gespeichert, aber Teile davon werden auf Verarbeitungsknoten, SSD oder sogar im RAM zwischengespeichert, um schnelleren Zugriff zu ermöglichen.

Mit der Zwischenspeicherungsrichtlinie können Sie auswählen, welche Daten zwischengespeichert werden sollen. Sie können zwischen hot data cache und cold data cache unterscheiden, indem Sie eine Zwischenspeicherungsrichtlinie für hot data festlegen. Hot data is stored in local SSD storage for faster query performance, while cold data is stored in reliable storage, which is billiger but langsamer to access.

Der Cache verwendet 95 % des lokalen SSD-Datenträgers für Hot Data. 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 sind. Dieses Design stellt sicher, dass Abfragen, die viele kalte Daten laden, keine heißen Daten aus dem Cache entfernt werden.

Die beste Abfrageleistung wird erreicht, wenn alle aufgenommenen Daten zwischengespeichert werden. Bestimmte Daten garantieren jedoch möglicherweise nicht, dass die Kosten im heißen Cache aufbewahrt werden. So könnten beispielsweise selten auf alte Protokolldatensätze zugegriffen werden, die weniger wichtig sind. In solchen Fällen entscheiden sich Teams häufig für eine geringere Abfrageleistung, um die Daten warm zu halten.

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

Hinweis

Informationen zur Verbrauchsrate finden Sie unter Eventhouse- und KQL-Datenbanknutzung.

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

Tipp

Ihr Cluster wurde für Ad-hoc-Abfragen mit Zwischenergebnissätzen entwickelt, die in den Gesamten RAM des Clusters passen. Bei großen Aufträgen wie der Kartenreduzierung kann es hilfreich sein, zwischengeschaltete Ergebnisse im beständigen Speicher zu speichern. Erstellen Sie dazu einen fortlaufenden Exportauftrag . Mit diesem Feature können Sie lang ausgeführte Batchabfragen mit Diensten wie HDInsight oder Azure Databricks ausführen.

Anwenden der Zwischenspeicherungsrichtlinie

Wenn Daten aufgenommen werden, verfolgt das System das Datum und die Uhrzeit der Aufnahme und des Umfangs, der erstellt wurde. Der Datums- und Uhrzeitwert des Umfangs (oder der Maximalwert, wenn ein Umfang aus mehreren vorhandenen Ausmaßen erstellt wurde) wird verwendet, um die Zwischenspeicherungsrichtlinie auszuwerten.

Hinweis

Sie können einen Wert für das Datum und die Uhrzeit der Aufnahme angeben, indem Sie die Aufnahmeeigenschaft creationTimeverwenden. Stellen Sie dabei sicher, dass die Lookback Eigenschaft in der effektiven Zusammenführungsrichtlinie der Tabelle mit den Werten übereinstimmt, für creationTimedie Sie festgelegt haben.

Standardmäßig ist nulldie effektive Richtlinie , was bedeutet, dass alle Daten als heiß betrachtet werden. Eine null Richtlinie auf Tabellenebene bedeutet, dass die Richtlinie von der Datenbank geerbt wird. Eine Richtlinie auf Nicht-Tabellenebenenull setzt eine Richtlinie auf Datenbankebene außer Kraft.

Bereichsdefinition von Abfragen in den heißen Cache

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

Hinweis

Die Datendefinition gilt nur für Entitäten, die Zwischenspeicherungsrichtlinien unterstützen, z. B. Tabellen und materialisierte Ansichten. Es 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 der 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 an, die bestimmen, dass die Abfrage alle Daten abdecken soll.

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

In der folgenden Abfrage verwenden beispielsweise alle Tabellenverweise nur Hot-Cache-Daten, mit Ausnahme des zweiten Verweises auf "T", der auf alle Daten festgelegt 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 ein optimales Verhältnis zwischen Kosten und Leistung zu erzielen, basierend auf dem erwarteten Abfragemuster.

Beispiel:

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

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