Mit dem Distributed Cache Service auf die Datenbank-Überholspur

In diesem Artikel lesen Sie,

• was hinter dem Distributed Cache Service (DCS) steckt,
• wann er seine Vorteile ausspielt
• und welche Möglichkeiten für das Zusammenspiel mit einer Datenbank existieren.

Wenn es schnell gehen muss oder viele Nutzer gleichzeitig betreut werden müssen, kommen Datenbanken schnell mal an ihre Grenzen – oder die User Experience sinkt drastisch. Mit dem Distributed Cache Service (DCS) gelingt hier schnelle Abhilfe. Unser Whitepaper zeigt, wie der DCS eingesetzt werden kann und zeigt anhand von Messdaten, was Nutzer der Open Telekom Cloud (sowohl Service-Anbieter als auch Endnutzer) für die Performance eines Service von DCS erwarten können.

Meistens tut es eine der klassischen relationalen Datenbanken aus dem Portfolio der Open Telekom Cloud, z.B. eine PostgreSQL oder MySQL-Datenbank. Wozu dann ein Cache-Service? Ist das ein Ersatz für eine Datenbank? Die Antwort – zumindest auf letztere Frage – ist ein klares Nein. Der DCS ist kein Ersatz für eine klassische Datenbank oder Dokumenten-Datenbank. Und Nutzer, die PostgreSQL für die Speicherung geschäftskritischer Daten nutzen, können durchatmen – sie müssen nichts ändern. Immer dann, wenn Datengrößen vorhersagbar und limitiert sind, Daten langfristig gespeichert werden sollen oder komplexe Szenarien realisiert werden müssen, sind relationale Datenbanken die unbestrittenen Königinnen der Szene. 

Wenn es um Millisekunden geht oder viele gleichzeitige Nutzer mit einer gleichbleibend hohen Nutzererfahrung (also ohne große Wartezeiten) betreut werden sollen, kann man als Service-Anbieter über einen DCS nachdenken. Der DCS ist ein (wie der Name schon sagt) verteilter, schneller Online-In-Memory-Cache-Dienst.  

Das heißt, er speichert Daten im Hauptspeicher, nicht auf Storage-Systemen wie klassische relationale Datenbanken. Er ist zuverlässig, skalierbar, „out of the box“ einsatzbereit und einfach zu verwalten. Was ihn auszeichnet: Er bietet hohe Lese-/Schreib-Leistung und einen schnellen Datenzugriff. DCS ist mit Redis kompatibel. Redis (Remote Dictionary Server) ist ein beliebter Open-Source-NoSQL-Datenspeicher. Er kann verschiedenste Datenstrukturen verarbeiten, z.B. Strings, also Texte, binäre Zahlenfolgen, Listen, Sets, Hashes, Geodaten-Indizes, etc. Eine komplette Liste der nutzbaren Datenstrukturen bietet das Whitepaper. 

Typische Einsatzszenarien, in denen solche Anforderungen aufkommen können, sind beispielweise Session Storing, Echtzeit-Analysen oder Machine Learning. Session Storing wird bei vielen häufig frequentierten Internet-Diensten eingesetzt. Hier verwaltet der Cache Service die für einen Besuch (eine „Session“) benötigten Daten eines Nutzers. Er stellt das spezielle Nutzerprofil bereit, die Credentials und die nutzerspezifische Personalisierung. Der Service erkennt den Nutzer so wieder – in Windeseile. 

Eine häufige Anforderung vieler Internet-Dienste ist auch die Echtzeit-Analyse von Daten aus Streams. Das Problem: Die Streams zeichnen sich dadurch aus, dass sie nicht „stehenbleiben“. In enger Taktung entstehen kontinuierlich neue Daten für den Stream, z.B. aus Social Media, IoT-Szenarien oder beim „Matchmaking“. Besuchen Nutzer bestimmte Webseiten, müssen anfallende und bestehende Daten schnell „verdaut“ und analysiert werden, damit der Besucher bspw. eine zeitnah personalisierte Werbung erhält oder der Service ihm/ihr auf Basis einer Echtzeit-Entscheidung ein passendes Angebot macht.

In unserem Whitepaper haben wir in drei Use Cases gemessen, wie sich steigende Nutzerzahlen auf die Performanz eines Online-Service auswirken – mit und ohne DCS. Die Verfügbarkeit häufig angefragter Daten, die Speicherung „vorläufiger“ Daten beim Anlegen eines Warenkorbs und die Bearbeitung temporärer, zu analysierender Daten für einen Kommentar. Die Daten belegen anschaulich, wie die Antwortzeiten beim DCS stabil bleiben, während sie beim Einsatz einer relationalen Datenbank sinken. Insgesamt bietet der DCS eine 5- bis 30-fache Geschwindigkeit.

Weil aber Daten auch dauerhaft gespeichert werden müssen, kommen Service-Anbieter nicht um eine kostengünstige Standard-Datenbank herum. Häufig entstehen so hybride Datenbank-Szenarien, in denen die relationale Datenbank das „Lastpferd“ für den Dauerbetrieb ist und der Distributed Cache Service als reaktiver Begleiter (vielleicht eine Art Windhund) fungiert, der schnell alles Außergewöhnliche anpackt oder vorverarbeitet. Unser Whitepaper zeigt fünf prinzipielle Architekturen auf, in denen der DCS mit einer klassischen Datenbank interagieren kann. 

Aktuell basiert der DCS der Open Telekom Cloud auf Redis. Im ersten Quartal 2025 wird Redis 7.x als Update ausgerollt. Redis 3 hingegen wird Mitte 2025 in Rente gehen. Nutzer der alten Version sollten also eine Migration auf eine neuere Version ins Auge fassen.