Trace Id is missing
Zum Hauptinhalt wechseln

Was ist Zwischenspeichern?

Entwickler und IT-Experten verwenden das Caching, um das Speichern von und den Zugriff auf Schlüssel-Wert-Daten im temporären Arbeitsspeicher zu beschleunigen und im Vergleich zur Speicherung im herkömmlichen Datenspeicher zu vereinfachen. Caches sind in verschiedenen Szenarios nützlich, bei denen mehrere Technologien eingesetzt werden. Beispiele dafür sind das Computercaching mit RAM (Random-Access Memory), das Netzwerkcaching in einem Content Delivery Network, Webcaches für Multimedia-Internetdaten oder Cloudcaches für die Verbesserung der Resilienz von Cloud-Apps. Entwickler entwerfen Anwendungen häufig so, dass verarbeitete Daten zwischengespeichert und dann neu verwendet werden, um Anforderungen schneller als bei gewöhnlichen Datenbankabfragen zu verarbeiten.

Mit Caching können Sie die Datenbankkosten senken und einen höheren Durchsatz und eine niedrigere Latenz als die meisten Datenbanken ermöglichen. Zudem können Sie die Leistung von Cloud- und Webanwendungen steigern.

Wie funktioniert das Caching für Datenbanken?

Entwickler können eine primäre Datenbank durch einen Datenbankcache ergänzen, den sie in der Datenbank oder Anwendung oder als eigenständige Schicht einrichten. Obwohl in der Regel eine herkömmliche Datenbank erforderlich ist, um große, beständige und vollständige Datasets zu speichern, wird in der Regel ein Cache verwendet, um temporäre Teilmengen der Daten zu speichern und diese schnell abrufen zu können.

Das Caching funktioniert mit sämtlichen Datenspeichern, darunter NoSQL-Datenbanken und relationale Datenbanken wie SQL Server, MySQL oder MariaDB. Auch mit vielen spezifischen Datenplattformen wie Azure Database for PostgreSQLAzure SQL-Datenbank oder Azure SQL Managed Instance ist das Caching kompatibel. Informieren Sie sich darüber, welcher Datenspeicher am besten zu Ihren Anforderungen passt, bevor Sie mit der Konfiguration einer Datenarchitektur beginnen. Sie sollten sich beispielsweise mit PostgreSQL vertraut machen, bevor Sie PostgreSQL verwenden, um relationale und unstrukturierte Datenspeicher zu kombinieren.

Was sind die Vorteile von Cacheschichten? Was ist Redis?

Entwickler verwenden mehrschichtige Caches (Cacheschichten), um verschiedene Daten je nach Bedarf in separaten Caches zu speichern. Durch das Hinzufügen einer oder mehrerer Cacheschichten können Sie den Durchsatz und die Latenzleistung einer Datenschicht erheblich verbessern.

Redis ist eine beliebte, quelloffene In-Memory-Datenstruktur, die für die Erstellung hochleistungsfähiger Cacheschichten und anderer Datenspeicher eingesetzt wird. Aus einer aktuellen Studie geht hervor, dass durch das Hinzufügen von Azure Cache for Redis zu einer Beispielanwendung der Datendurchsatz um über 800 Prozent und die Latenzleistung um über 1.000 Prozent1 gesteigert werden konnte.

Caches können auch die Gesamtkosten für eine Datenschicht reduzieren. Wenn Sie Caches verwenden, um die häufigsten Abfragen zu verarbeiten und die Datenbankauslastung zu reduzieren, können Sie auch die überdimensionierte Bereitstellung von Datenbankinstanzen eindämmen und so erhebliche Kosteneinsparungen erzielen sowie die Gesamtkosten senken.

Arten des Caching

Die empfohlene Cachingstrategie hängt davon ab, wie Ihre Anwendung Daten liest und schreibt. Ist es eine schreibintensive Anwendung, oder werden Daten nur einmal geschrieben, aber häufig gelesen? Sind die zurückgegebenen Daten immer eindeutig? Verschiedene Datenzugriffsmuster beeinflussen die Konfiguration eines Caches. Zu den gängigen Cachingarten zählen ein cachefremder Ansatz, Read-Through-/Write-Through-Caches und Write-Behind-/Write-Back-Caches.

Cachefremd

Für Anwendungen mit leseintensiven Workloads setzen Entwickler häufig ein cachefremdes Programmiermuster (auch "Nebencache") ein. Der Nebencache befindet sich außerhalb der Anwendung und kann dann eine Verbindung mit dem Cache herstellen, um Daten abzufragen oder abzurufen. Falls die Daten sich nicht im Cache befinden, kann auch eine direkte Verbindung mit der Datenbank hergestellt werden. Wenn die Anwendung die Daten abruft, kopiert sie sie für zukünftige Abfragen in den Cache.

Mit einem Nebencache können Sie die Anwendungsleistung verbessern, für Konsistenz zwischen dem Cache und dem Datenspeicher sorgen und die Daten im Cache vor Veraltung schützen.

Read-Through-/Write-Through-Cache

Read-Through-Caches bleiben stets auf dem aktuellen Stand. Beim Write-Through-Cache hingegen schreibt die Anwendung die Daten zuerst in den Cache und dann in die Datenbank. Beide Caches sind mit der Datenbank synchronisiert, und die Anwendung behandelt diese als Hauptdatenspeicher.

Read-Through-Caches vereinfachen Anwendungen, bei denen immer wieder dieselben Daten angefordert werden. Der Cache selbst ist jedoch komplexer, und der zweistufige Write-Through-Vorgang kann sich negativ auf die Latenz auswirken. Entwickler koppeln diese beiden Ansätze, um Datenkonsistenz zwischen dem Cache und der Datenbank zu erzielen, die Latenz des Write-Through-Caches zu verringern und das Aktualisieren des Read-Through-Caches zu vereinfachen.

Mit dem Read-Through-/Write-Through-Caching können Entwickler den Anwendungscode vereinfachen, die Skalierbarkeit des Caches erhöhen und die Auslastung der Datenbank minimieren.

Write-Behind-/Write-Back-Cache

In diesem Szenario schreibt die Anwendungen Daten zurück in den Cache. Der Vorgang wird sofort bestätigt. Dann schreibt der Cache die Daten im Hintergrund zurück in die Datenbank. Write-Behind-Caches (auch: Write-Back-Caches) eignen sich optimal für schreibintensive Workloads. Sie verbessern die Schreibleistung, da die Anwendung nicht warten muss, bis ein Schreibvorgang abgeschlossen ist, bevor sie zum nächsten Task übergeht.

Verteilter Cache und Sitzungsspeicher im Vergleich

Häufig werden verteilte Caches mit Sitzungsspeicher verwechselt. Es bestehen zwar Ähnlichkeiten, doch es gibt unterschiedliche Anforderungen und Anwendungszwecke. Anstatt einen verteilten Cache zu verwenden, um eine Datenbank zu ergänzen, implementieren Entwickler Sitzungsspeicher, bei denen es sich um temporäre Datenspeicher auf der Benutzerschicht handelt, für Profile, Nachrichten und andere Benutzerdaten in sitzungsorientierten Anwendungen wie Web-Apps.

Was ist ein Sitzungsspeicher?

Sitzungsorientierte Anwendungen verfolgen die Aktionen der Benutzer nach, während diese bei den Anwendungen angemeldet sind. Diese Daten können nach der Abmeldung eines Benutzers in einem Sitzungsspeicher aufbewahrt werden. So verbessern Sie die Sitzungsverwaltung, senken die Kosten und beschleunigen die Anwendungsleistung.

Wie unterscheidet sich die Verwendung eines Sitzungsspeichers von der Zwischenspeicherung einer Datenbank?

In einem Sitzungsspeicher werden Daten nicht von verschiedenen Benutzern gemeinsam genutzt, während beim Caching verschiedene Benutzer auf denselben Cache zugreifen können. Entwickler verwenden das Caching, um die Leistung einer Datenbank- oder Speicherinstanz zu verbessern. Sitzungsspeicher werden hingegen verwendet, um die Anwendungsleistung zu steigern, indem Daten in den In-Memory-Speicher geschrieben werden, sodass kein Zugriff auf eine Datenbank mehr notwendig ist.

In einen Sitzungsspeicher geschriebene Daten sind meistens kurzlebig, während in einer primären Datenbank zwischengespeicherte Daten in der Regel deutlich langlebiger sind. Für einen Sitzungsspeicher sind Replikation, Hochverfügbarkeit und Datenbeständigkeit erforderlich, damit Transaktionsdaten nicht verloren gehen und die Benutzer aktiv bleiben. Andererseits ist immer eine Kopie der Daten in der permanenten Datenbank vorhanden, falls die Daten im Nebencache verloren gehen.

Vorteile des Caching

Verbesserte Anwendungsleistung

Es ist deutlich schneller, die Daten aus einem In-Memory-Cache zu lesen als über einen datenträgergestützten Datenspeicher auf diese zuzugreifen. Durch den schnelleren Datenzugriff verbessert sich auch die Gesamtleistung der Anwendung erheblich.

Reduzierte Datenbanknutzung und -kosten

Durch das Caching sind weniger Datenbankabfragen nötig, sodass die Leistung verbessert und die Kosten gesenkt werden, da die Datenbankinfrastruktur seltener hochskaliert werden muss und die Durchsatzgebühren sinken.

Skalierbare und vorhersagbare Leistung

Eine einzelne Cacheinstanz kann Millionen von Anforderungen pro Sekunde verarbeiten und bietet ein Maß an Durchsatz und Skalierbarkeit, das Datenbanken nicht erreichen können. Das Caching bietet außerdem die benötigte Flexibilität für die Auf- oder Hochskalierung Ihrer Anwendungen und Datenspeicher. Anschließend kann Ihre Anwendung vielen Benutzern den gleichzeitigen Zugriff auf dieselben Dateien ermöglichen, ohne die Auslastung der Back-End-Datenbanken zu erhöhen. Wenn bei einer Anwendung häufig Auslastungsspitzen und ein hoher Durchsatz auftreten, kann die Latenz zudem durch In-Memory-Caches verringert werden.

Wofür wird das Caching verwendet?

Ausgabecaching

Das Ausgabecaching verbessert die Webseitenleistung, da der vollständige Quellcode (z. B. HTML-Code und Clientskripts) gespeichert wird, den ein Server zu Renderingzwecken an Browser sendet. Bei jedem Benutzeraufruf speichert der Server den Ausgabecode im Arbeitsspeicher der Anwendung zwischen. Dadurch kann die Anwendung Anforderungen verarbeiten, ohne Seitencode ausführen oder mit anderen Servern kommunizieren zu müssen.

Datencaching und Datenbankcaching

Die Geschwindigkeit und der Durchsatz einer Datenbank können wichtige Faktoren für die Gesamtleistung der Anwendung sein. Das Datenbankcaching wird für regelmäßige Aufrufe von Daten verwendet, die nur selten geändert werden, zum Beispiel Preis- oder Bestandsdaten. So können Websites und Anwendungen schneller geladen werden, während gleichzeitig der Durchsatz verbessert und die Latenz für Datenabrufe von Back-End-Datenbanken verringert wird.

Benutzersitzungsdaten speichern

Anwendungsbenutzer generieren häufig Daten, die für kurze Zeiträume gespeichert werden müssen. Ein In-Memory-Datenspeicher wie Redis ist ideal, um große Mengen von Sitzungsdaten wie Benutzereingaben, Warenkorbeinträge und Personalisierungseinstellungen effizient und zuverlässig zu speichern – und das zu geringeren Kosten als für Speicher oder Datenbanken üblich.

Nachrichtenbrokerarchitekturen und Pub/Sub-Architekturen

Cloudanwendungen müssen häufig Daten zwischen Diensten austauschen und können das Caching verwenden, um Pub/Sub-Architekturen oder Nachrichtenbrokerarchitekturen zu implementieren, die die Latenz verringern und die Datenverwaltung beschleunigen.

Anwendungen und APIs

Genau wie Browser speichern auch Anwendungen wichtige Dateien und Daten, um diese bei Bedarf schnell neu zu laden. Zwischengespeicherte API-Antworten verringern die Auslastung von Anwendungsservern und Datenbanken und sorgen für schnellere Antwortzeiten und eine bessere Leistung.

[1] Die Leistungsansprüche wurden auf der Grundlage einer Studie erhoben, die von Microsoft in Auftrag gegeben und von GigaOm im Oktober 2020 durchgeführt wurde. Die Studie vergleicht die Leistung einer Testanwendung, die eine Azure-Datenbank verwendet, mit und ohne Implementierung von Azure Cache for Redis als Cachinglösung. Azure SQL-Datenbank und Azure Database for PostgreSQL wurden in der Studie als Datenbankelemente verwendet. Eine Universell-Instanz von Azure SQL-Datenbank (Gen5) mit zwei virtuellen Kernen und eine Universell-Instanz von Azure Database for PostgreSQL mit zwei virtuellen Kernen wurden in Kombination mit einer Premium P1-Instanz von Azure Cache for Redis mit 6 GB verwendet. Die Ergebnisse wurden mit Universell-Instanzen von Azure SQL-Datenbank (Gen5) mit 8, 16, 24 und 32 virtuellen Kernen und mit Universell-Instanzen von Azure Database for PostgreSQL mit 8, 16, 24 und 32 virtuellen Kernen ohne Azure Cache for Redis verglichen. Die Benchmarkdaten stammen aus dem Web Application Database Load Test von GigaOm, der eine gängige Webanwendung und eine Back-End-Datenbank simuliert, die mit einer steigenden Anzahl von HTTP-Anforderungen konfrontiert werden. Die tatsächlichen Ergebnisse können je nach Konfiguration und Region variieren. Lesen Sie die vollständige Studie.

Kostenloses Konto

Testen Sie Azure Cloud Computing-Dienste bis zu 30 Tage lang kostenlos.

Nutzungsbasierte Bezahlung

Starten Sie mit nutzungsbasierter Bezahlung. Sie müssen vorab keine Verpflichtung eingehen und können jederzeit kündigen.

Fügen Sie Ihrer Anwendung mithilfe eines vollständig verwalteten Redis-Diensts eine schnelle Cacheschicht hinzu. Erfahren Sie mehr über die ersten Schritte mit Azure Cache for Redis.

Informieren Sie sich über Azure HPC Cache, wenn Sie ein flexibles, dateibasiertes Caching für Hochleistungsanwendungen benötigen.