Thought Leadership
Nachdem sich Teil 1 mit Application-Caching-Strategien beschäftigt hat, widmet sich dieser Beitrag nun den Caching-Topologien und Bereinigungsstrategien. Moderne Caches kommen in drei unterschiedlichen Systemtypen vor. Nachfolgend erläutern ihre Vor- und Nachteile auf.
In-Process-Caches
Der In-Process-Cache kommt am häufigsten in nichtverteilten Systemen zum Einsatz. Der Cache wird im Arbeitsspeicher der Anwendung selbst beibehalten und bietet die schnellstmögliche Zugriffsgeschwindigkeit.
Dieser Cachetyp kommt beim Caching von Datenbanken zum Einsatz. Er kann allerdings auch als eine Art Objektpool dienen, zum Beispiel durch Pooling der zuletzt genutzten Netzwerkverbindungen, die zu einem späteren Zeitpunkt nochmals verwendet werden sollen.
Bild 1: Einsatz bei Datenbanken.
Vorteile:
- Höchste Zugriffsgeschwindigkeit
- Daten lokal verfügbar
- Wartungsfreundlich
Nachteile:
- Datenredundanz bei mehreren Applikationen
- Hoher Verbrauch an Arbeitsspeicher an jedem einzelnen Knoten
- Zwischengespeicherte Daten im Arbeitsspeicher der Anwendung
- Anscheinend einfacher Aufbau, allerdings mit versteckten Herausforderungen
Caches in eingebetteten Knoten
Durch die Verwendung eines im Knoten eingebetteten Caches wird die Applikation selbst Teil des Clusters. Diese Caching-Topologie ist eine Kombination aus einem In-Process-Cache sowie dem Cooperative Caching und kann entweder die Partitionierung oder eine vollständige Datensatzreplikation nutzen.
Bei der vollständigen Replikation profitiert die Anwendung von den Vorteilen eines In-Process-Cache, da alle Daten lokal zur Verfügung stehen (höchste Zugriffsgeschwindigkeit). Allerdings geht das zu Lasten des Arbeitsspeichers und der Datenmenge.
Bei der Datenpartitionierung weiß die Anwendung, wo die angefragten Daten liegen und fordert sie direkt über eine bereits bestehende Datenverbindung an. Die Geschwindigkeit ist zwar geringer als bei lokal verfügbaren Daten, aber weiterhin akzeptabel.
Bild 2: Die Kombi macht’s.
Vorteile:
- Daten können bei höchster Zugriffsgeschwindigkeit repliziert werden
- Daten können zum Erstellen größerer Datensätze partitioniert werden
- Zwischengespeicherte Daten dienen mehreren Applikationen als gemeinsamer Statusbericht
- Die Applikation selbst kann skaliert werden
Nachteile:
- Hohe Wiederholungsrate bei Replikation
- Anwendung und Cache können nicht unabhängig voneinander skaliert werden
- Daten werden im Arbeitsspeicher der Anwendung zwischengelagert
Lesen Sie auch den anderen Beitrag der Serie „Big Data“:
Teil 1: Application-Caching-Strategien
Teil 2: Caching-Topologien und Bereinigungsstrategien
C/S-Architekturen
EinClient–Server-Cache ist heute einer der gängigsten Setups (neben dem reinen In-Process-Cache).Oftmals agieren diese Systeme als Cooperative Caches, da sie als Multi-Server-Architektur skalieren und dabei das gleiche Feature Set aufweisen wie ein Cache in einem eingebetteten Knoten – bloß mit einer zusätzlichen Client-Ebene.
Diese Architektur pflegt separate Cluster der Anwendungen, nutzt hierfür die zwischengespeicherten Daten sowie die Daten selbst und bietet daher die Möglichkeit, Anwendungs- und Caching-Cluster unabhängig voneinander zu skalieren. Anstelle eines Caching-Clusters ist es ebenso möglich, einen Caching-Server einzusetzen. So wird aber immer seltener verfahren.
Die Zugriffsmuster auf eine Client-Server-Cache-Architektur sind vergleichbar mit denen auf eine externe relationale Datenbank oder andere netzwerkgebundenen Backend-Ressourcen.
Bild 3: C/S – heute Commodity.
Vorteile:
- Daten können für höchste Zugriffsgeschwindigkeit repliziert werden
- Daten können zum Erstellen größerer Datensätze partitioniert werden
- Zwischengespeicherte Daten dienen mehreren Applikationen als gemeinsamer Statusbericht Anwendungen und Cache können unabhängig voneinander skaliert werden
- Anwendungen können ohne Datenverlust neu gestartet werden
Nachteile:
- Hohe Wiederholungsrate bei Replikation
- Stets zusätzlicher Netzwerk-Roundtrip (schnelles Netzwerk)
Least Frequently Used (LFU)
Die Bereinigungsstrategie Least Frequently Used entfernt Werte, auf die am wenigsten zugegriffen wird. Für die Analyse zeichnet jeder Datensatz seine Zugriffe mit einem Zähler auf, der nur weiter hochzählt. Das Ergebnis kann mit jenen für andere Datensätze zum Feststellen des LFU-Elements verglichen werden.
Bild 4: Bereinigungsstrategie 1.
Vorteile:
- Berücksichtigt das Alter des Elements
- Berücksichtigt Bezugsfrequenz des Elements
- Funktioniert besser unter hoher Belastung, wenn schnell viele Elemente angefordert werden (höhere Trefferquote)
Nachteile:
- Ein häufig angefragtes Element wird nur nach zahlreichen Fehlern entfernt
- Man muss mehr darauf achten, ungültige Elemente, die sich ändern, als solche zu deklarieren
Least Recently Used (LRU)
Die Bereinigungsstrategie Least Recently Used entfernt Werte, die lange nicht verwendet wurden. Jeder Datensatz zeichnet seine letzte Zugriffszeit auf, die mit anderen Datensätzen verglichen werden kann, um das letzte LRU-Element festzustellen.
Bild 5: Bereinigungsstrategie 2.
Vorteile:
- Ist dem optimalen Algorithmus am nächsten
- Wählt Elemente aus und entfernt solche, die länger nicht verwendet wurden
Nachteile:
- Teils geringe Erfolgsquote, da es meist wichtiger ist, wie oft auf ein Element zugegriffen wurde, als wann dies zuletzt erfolgt ist
Andere Bereinigunsstrategien
Abgesehen von LRU und LFU wurden im Laufe der letzten zehn Jahre eine Reihe anderer Bereinigungsstrategien entwickelt. Sie verfolgen unterschiedliche Ziele. Einige versuchen, bessere Treffer zu landen benötigen dafür aber viel Processing-Leistung oder Metadaten. Andere kombinieren die beiden vorherigen Strategien oder – im einfachsten Fall – wählen einfach zufällig Einträge aus.
Je nach Ziel unterscheiden sich Erfolg und Effizienz hinsichtlich der bereinigten Elemente. Eine komplette Übersicht anderer häufig verwendeter Bereinigungsstrategien sind auf Wikipedia zu finden.
Weitere Informationen:
Teil 1 dieser Serie hat sich mit dem Thema Application-Caching-Strategien beschäftigt.
Christoph Engelbert, Technical Evangelist Senior Solutions Architect bei Hazelcast
