Write Behind Cache
Erst in den Cache, später in die Datenbank schreiben
Die Idee und ihr Nutzen
Kunden einer Versicherung können einen Schaden online im Schadenportal melden. Damit ein Kunde die Meldung unterbrechen und später fortsetzen kann, speichert das Schadenportal die Eingaben des Kunden laufend als Entwurf. Das Schadenportal schreibt den Entwurf nach jeder Eingabe aber nicht sofort in die Datenbank, sondern legt ihn zunächst in einem Cache ab, einem Zwischenspeicher im Arbeitsspeicher. Ein Hintergrundprogramm überträgt die geänderten Entwürfe später gesammelt in die Datenbank. Das Schadenportal muss dadurch nach einer Eingabe nicht auf die Datenbank warten, und die Datenbank wird weniger belastet. Dieses Vorgehen heißt Write Behind, auf Deutsch etwa nachträgliches Schreiben, und der Cache dafür Write Behind Cache. Der Name meint: Eine Eingabe gelangt erst hinterher in die Datenbank, nachdem das Schadenportal dem Kunden schon „Entwurf gespeichert“ angezeigt hat.
Wie funktioniert es?
Frau Albers, eine Kundin der Versicherung, meldet nach einem Sturm online, dass Ziegel von ihrem Dach gefallen sind. Um 14:00:00 Uhr schreibt das Hintergrundprogramm ihren Entwurf in die Datenbank. Der Entwurf enthält zu diesem Zeitpunkt Datum und Ort des Schadens. Die Datenbank bestätigt das Speichern, und das Hintergrundprogramm vermerkt den Entwurf als übertragen. Danach trägt Frau Albers die Beschreibung „Sturm hat Ziegel abgedeckt, Wasser auf dem Dachboden“ und eine geschätzte Schadenhöhe von 3.000 Euro ein. Das Schadenportal legt den ergänzten Entwurf in Bruchteilen einer Millisekunde im Cache ab und zeigt sofort „Entwurf gespeichert“ an, ohne auf die Datenbank zu warten. Die neuen Angaben stehen bisher nur im Cache. Um 14:00:22 Uhr schließt Frau Albers das Browserfenster, um Fotos vom Dach zu machen. Um 14:00:25 Uhr fällt der Cache aus, fünf Sekunden vor der nächsten Übertragung um 14:00:30 Uhr. Beschreibung und Schadenhöhe erreichen die Datenbank nicht, dort stehen weiterhin nur Datum und Ort. Am Abend öffnet Frau Albers ihre Meldung wieder. Der Cache ist nach dem Ausfall leer, deshalb lädt das Schadenportal den Entwurf aus der Datenbank. Beschreibung und Schadenhöhe fehlen, und Frau Albers trägt beides noch einmal ein. Zum Schluss schickt sie die fertige Meldung mit Fotos ab. Für die abgeschickte Meldung verwendet das Schadenportal das nachträgliche Schreiben nicht: Es schreibt die Meldung sofort in die Datenbank und zeigt Frau Albers die Schadennummer erst an, nachdem die Datenbank das Speichern bestätigt hat.
Der Cache hält für jeden Kunden den neuesten vollständigen Entwurf. Im Cache ersetzt jeder neue Stand den bisherigen Entwurf des Kunden, und der Cache merkt sich, welche Entwürfe sich seit der letzten Übertragung geändert haben. Das Hintergrundprogramm liest alle 30 Sekunden die geänderten Entwürfe aus dem Cache und schreibt sie in einem Schwung in die Datenbank. Füllt ein Kunde in dieser Zeit fünf Felder aus, wird aus seinen fünf Eingaben so ein einziger Schreibvorgang. Die Datenbank speichert Entwürfe und abgeschickte Schadenmeldungen dauerhaft. Den Abstand von 30 Sekunden legt das Entwicklungsteam des Schadenportals fest: Ein längerer Abstand entlastet die Datenbank stärker, aber bei einem Ausfall des Cache gehen dann mehr Eingaben verloren. Bei 30 Sekunden verliert ein Kunde durch einen Ausfall höchstens die Eingaben einer halben Minute.
Dass eine als gespeichert gemeldete Eingabe bei einem Ausfall des Cache verloren gehen kann, hat das Entwicklungsteam für Entwürfe bewusst in Kauf genommen. Solange der Kunde die Seite geöffnet hat, sieht er seine Eingaben ohnehin auf dem Bildschirm. Gehen die letzten Eingaben verloren, muss er sie noch einmal eintragen. Das ist ärgerlich, dauert aber nur wenige Minuten. Eine falsche Zahlung oder eine verlorene Schadenmeldung entsteht dadurch nicht. Schlägt eine Übertragung fehl, versucht das Hintergrundprogramm es erneut. Weil das Hintergrundprogramm immer den vollständigen Entwurf schreibt, ist ein zweiter Versuch unbedenklich, solange noch kein neuerer Stand desselben Entwurfs übertragen wurde: Die Datenbank erhält denselben Entwurf noch einmal.
Write-Behind Cache: Entwurf sofort im Cache, alle 30 Sekunden in die Datenbank
Wann ist es sinnvoll und wann nicht?
Ein Write Behind Cache lohnt sich
- Die Fachabteilung erlaubt, dass Änderungen verzögert in die Datenbank gelangen und bei einem Ausfall des Cache die Änderungen einer halben Minute verloren gehen. Das gilt etwa für die Entwürfe, die ein Kunde notfalls in wenigen Minuten neu eingibt. Ohne Write Behind behandelt das Schadenportal jeden Entwurf wie eine abgeschickte Schadenmeldung und wartet bei jeder Eingabe, bis die Datenbank das Speichern bestätigt hat.
- Viele kleine Änderungen an denselben Daten treffen kurz nacheinander ein und lassen sich zu wenigen Schreibvorgängen zusammenfassen. Ein Beispiel sind die Eingaben eines Kunden, die das Schadenportal nach jedem ausgefüllten Feld speichert. Ohne Write Behind werden aus fünf ausgefüllten Feldern fünf Schreibvorgänge in der Datenbank, mit Write Behind wird daraus einer.
- Lastspitzen würden die Datenbank sonst so auslasten, dass wichtigere Schreibvorgänge langsamer werden. Nach einem Sturm melden Tausende Kunden zur selben Zeit ihre Schäden, und dann kommt es besonders auf die abgeschickten Schadenmeldungen an. Mit Write Behind erhält die Datenbank die Entwürfe nur alle 30 Sekunden gesammelt und kann die abgeschickten Schadenmeldungen weiterhin ohne Verzögerung speichern.
- Die Kunden sollen nach jedem ausgefüllten Feld sofort „Entwurf gespeichert“ sehen. Schreibt das Schadenportal jeden Entwurf direkt in die Datenbank, warten die Kunden nach jedem Feld auf diese Anzeige, bis die Datenbank das Speichern bestätigt hat.
Ein Write Behind Cache ist nicht das Richtige
- Die Daten dürfen nach der Bestätigung nicht verloren gehen. Beispiele sind abgeschickte Schadenmeldungen, Auszahlungen und Vertragsänderungen. Mit Write Behind stünde eine bestätigte Schadenmeldung bis zur nächsten Übertragung nur im Cache. Stattdessen schreibt das Schadenportal diese Daten sofort in die Datenbank, wie die abgeschickte Schadenmeldung von Frau Albers. Soll der Cache trotzdem den neuesten Stand halten, setzt das Entwicklungsteam einen Write Through Cache ein: Der Cache gibt jede Änderung sofort an die Datenbank weiter und meldet sie erst nach Bestätigung durch die Datenbank als erledigt. Das Schadenportal wartet dafür bei jeder Änderung auf die Datenbank, aber eine bestätigte Änderung geht bei einem Ausfall des Cache nicht verloren. Der Write Through Cache setzt voraus, dass die Datenbank die Zahl der Schreibvorgänge verkraftet.
- Andere Programme lesen direkt aus der Datenbank und brauchen den neuesten Stand. Ein Beispiel ist die Anwendung der Telefonberatung, mit der ein Mitarbeiter einem anrufenden Kunden bei seinem Entwurf hilft. Die Anwendung der Telefonberatung findet bis zur nächsten Übertragung einen älteren Stand als den im Cache. Dann schreibt das Schadenportal jede Änderung sofort in die Datenbank, zum Beispiel über einen Write Through Cache. Die Anwendung der Telefonberatung liest danach immer den Stand, den der Kunde zuletzt gespeichert hat.
- Es geht vor allem darum, die Datenbank zu entlasten, und die Kunden müssen nicht nach jedem ausgefüllten Feld „Entwurf gespeichert“ sehen. Dann lässt das Entwicklungsteam das Schadenportal den Entwurf seltener speichern und dabei direkt in die Datenbank schreiben. Ein Beispiel ist das Speichern nur beim Wechsel auf die nächste Seite des Formulars. Cache und Hintergrundprogramm, die betrieben und überwacht werden müssten, entfallen, und keine als gespeichert gemeldete Eingabe geht bei einem Ausfall verloren.
Nachteile und typische Fehler
Das Entwicklungsteam muss mit der Fachabteilung vereinbaren, für welche Daten ein Verlust bereits bestätigter Änderungen hinnehmbar ist. Neben Cache und Datenbank muss auch das Hintergrundprogramm betrieben werden. Die Reihenfolge der Übertragungen, Wiederholungen nach Fehlern und die Menge der noch nicht übertragenen Änderungen müssen überwacht werden, damit zum Beispiel kein älterer Entwurf einen neueren in der Datenbank überschreibt.
Typische Fehler und woran man sie erkennt:
- Verlust bestätigter Änderungen: Das Schadenportal hat für Eingaben schon „Entwurf gespeichert“ angezeigt. Der Cache fällt vor der nächsten Übertragung aus, und diese Eingaben fehlen in der Datenbank. Erkennbar ist das an fortgesetzten Entwürfen, in denen zuletzt eingegebene Angaben fehlen, wie Beschreibung und Schadenhöhe bei Frau Albers.
- Wachsender Rückstand: Nach einem Sturm ändern Tausende Kunden zugleich ihre Entwürfe. Braucht das Hintergrundprogramm für eine Übertragung länger als 30 Sekunden, kommt es mit dem Schreiben nicht nach, und im Cache sammeln sich immer mehr nicht übertragene Änderungen. Fällt der Cache dann aus, verlieren die Kunden nicht nur die Eingaben einer halben Minute, sondern alle Eingaben seit der letzten gelungenen Übertragung. Erkennbar ist das an einer wachsenden Zahl nicht übertragener Entwürfe im Cache.
- Älterer Entwurf überschreibt neueren: Eine Übertragung des Entwurfs von Frau Albers scheitert. Bei der nächsten Übertragung schreibt das Hintergrundprogramm schon einen neueren Stand dieses Entwurfs in die Datenbank. Danach wiederholt das Hintergrundprogramm die gescheiterte Übertragung und schreibt den älteren Stand über den neueren. Erkennbar ist das an Entwürfen, denen Angaben fehlen, obwohl der Cache nicht ausgefallen ist.
- Ungeeignete Daten: Das Entwicklungsteam verwendet das nachträgliche Schreiben auch für die abgeschickte Schadenmeldung. Bei einem Ausfall des Cache gehen dann Meldungen verloren, für die Kunden schon eine Bestätigung gesehen haben. Erkennbar ist das an Kunden, die eine Bestätigung vorweisen, zu der die Datenbank keine Meldung enthält.
Weiterführend
Verwandte Ansätze
- Cache Aside: Die Anwendung schreibt Änderungen selbst in die Datenbank und löscht die alte Kopie im Cache. Der Cache dient dabei nur dem schnelleren Lesen.
- Idempotency: beschreibt Vorgänge, deren Wiederholung nichts zusätzlich verändert, wie die wiederholte Übertragung desselben Entwurfs.
- Batch Processing: verarbeitet viele gesammelte Datensätze in einem Lauf, so wie das Hintergrundprogramm alle 30 Sekunden die geänderten Entwürfe gesammelt schreibt.
Quellen
- Oracle: Caching Data Sources (Oracle Coherence 14.1.1): beschreibt Write Behind mit Verzögerung, dem Zusammenfassen mehrerer Änderungen desselben Eintrags zu einem Schreibvorgang, Wiederholungen nach Fehlern und dem Hinweis, dass der Cache bis zur Übertragung die einzige Fassung der Daten hält.
- Hazelcast: Configuring a MapStore: Dokumentation zur Einstellung der Verzögerung, nach der Änderungen in die Datenbank geschrieben werden, und zum Zusammenfassen mehrerer Änderungen desselben Eintrags, sodass nur die letzte geschrieben wird.