Open Source im professionellen Einsatz
Linux-Magazin 11/2007
615

Datenpersistenz

An dieser Stelle drängt sich der Einwand auf, dass trotzdem die Daten irgendwie persistent auf der Platte liegen sollen. Auch wenn Linux noch so stabil läuft und die Hardware sicher vor Ausfällen wäre - spätestens bei einem Software-Update ist ein Neustart notwendig.

Die Datenspeicherung ist ein wichtiger Teil von LOA, sozusagen das Filetstück. Das an sich einfache Konzept hat erstaunliche Vorteile, wie später zu sehen sein wird. Die Idee: Da Lesezugriffe grundsätzlich aus dem Hauptspeicher bedient werden, müssen die Daten auf der Festplatte nicht für schnelles Lesen optimiert sein. Daher kann LOA alle Daten einfach sequenziell in eine Datei schreiben, die Persistenzdatei.

Für jeden Datensatztyp definiert der Entwickler ein binäres Format. Bei jeder Neuanlage oder Änderung eines Datensatzes, hängt er ihn in Binärform hinten an die Persistenzdatei an. Beim Löschen platziert er einfach einen Löschvermerk dahinter. Den prinzipiellen Aufbau des im Tauschzone-Projekt verwendeten Binärformats zeigt der Kasten "Binär gespeichert".

Binär
gespeichert

Abbildung 2 zeigt den Aufbau des in der Tauschzone verwendeten Binärformats. Folgende vier Chunk-Typen sind definiert:

  • CHUNK_EDIT_ARTICLE: Anlegen oder Ändern von Artikeln
  • CHUNK_DEL_ARTICLE: Artikel löschen
  • CHUNK_EDIT_USER: Anlegen oder Ändern von Benutzern
  • CHUNK_DEL_USER: Benutzer löschen

Für jeden Datensatztyp (Benutzer, Artikel) und für jedes Feld des Satzes gibt es einen Unterchunk-Typ, zum Beispiel »AC_ID« für die Artikel-ID und »UC_EMAIL« für die E-Mail-Adresse eines Benutzers. Die Strings sind so aufzufüllen, dass alle Chunks an 4-Byte-Grenzen ausgerichtet sind. Abbildung 3 zeigt die Datenstruktur bei der Änderung des Titels von Artikel Nummer 4711.

Abbildung 2: Das Binärformat der Tauschzone.

Abbildung 3: Datenstruktur beim Ändern des Titels von Artikel 4711.

Damit die Datei nicht unentwegt wächst, ist regelmäßig ein Bereinigen von veralteten und gelöschten Datensätzen nötig. Dazu legt das Programm einfach eine neue Persistenzdatei an und schreibt alle Datensätze einmal komplett heraus. Bei einem Neustart liest es die Persistenzdatei von Anfang an sequenziell ein und baut alle Datensätze im Hauptspeicher auf. Dabei werden auch in der Datei vorhandene Änderungen und Löschungen nachvollzogen. Die Hauptspeicher-Datenbank macht sozusagen im Eiltempo die komplette Änderungsgeschichte seit der letzten Bereinigung durch.

Replikation und Onlinesicherung geschenkt

Dies mag zunächst nach einer sehr langwierigen Operation aussehen. Da LOA aber mit Binärformaten arbeitet und eine sehr effiziente Verwaltung der Daten im Speicher verwendet, liegen die Zeiten selbst bei GBytes an Daten lediglich im Bereich von einigen Minuten. Die Tauschzone speichert in 4 GByte etwa eine Million Artikel.

So einfach das Speicherkonzept auf den ersten Blick wirken mag, so vielfältig sind die Vorteile, die sich aus dieser Lösung ergeben:

  • Die Persistenz kostet kaum CPU-Zeit - und auch das nur
    bei Änderungen. Das Schreiben der Daten auf Platte kann zudem
    asynchron geschehen. Somit blockiert es nicht den
    Hauptprozess.
  • Im laufenden Betrieb lässt sich jederzeit ein Snapshot der
    Daten anlegen. Dazu verwendet man die gleiche Funktion wie beim
    Bereinigen. Der Snapshot kann auf einem anderen System sofort
    gestartet werden (zum Beispiel zu Testzwecken).
  • Der LOA-Server kann parallel in zwei Dateien oder sogar
    TCP-Kanäle schreiben. Auf diese Art erledigt die Tauschzone
    online über SSH kontinuierlich ihr Backup.
  • Wenn ein LOA-Server seine Daten über TCP schreibt, kann
    ein zweiter Server sie kontinuierlich einlesen und in seine
    Datenbank einpflegen. Verhindert man bei diesem Schreibzugriffe,
    entsteht ein Online-Replikat, das stets mit dem ersten Server
    identisch ist. Es kann entweder zur Lastverteilung dienen oder bei
    einem Ausfall des ersten Servers diesen ersetzen (Abbildung
    4).

Abbildung 4: Mögliches Schema für die Replikation der im Speicher gehaltenen Daten.

Gerade die beiden letzten Punkte beschreiben Funktionen, die bei relationalen Datenbanken viel Geld und Administrationsaufwand kosten.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Meteor

    Javascript sowohl im Browser als auch auf dem Server: Das Webframework Meteor verspricht Anwendungen aus einem Guss, die sich dank vieler fertiger Pakete rasch programmieren lassen.

  • Backbone.js

    Die Javascript-Engines moderner Browser sind leistungsfähig genug, um die Anwendungslogik zu übernehmen. Wie auf dem Server beschleunigen auch hier Frameworks die Entwicklung. Ein herausragendes Beispiel für diese Gattung ist Backbone.js, das ein lokales Datenmodell umsetzt.

  • Gesichert wie eine Bank

    Die beliebte Open-Source-Datenbank MySQL kennt verschiedene Möglichkeiten der Datensicherung. Jede hat Vor- und Nachteile, die jedoch nur unter bestimmten Umständen gravierend sind.

  • Django

    Alle befragten Django-Entwickler waren über die vom Linux-Magazin gestellte Aufgabe nicht glücklich: Mit einem CMS sei das wesentlich einfacher zu lösen, hieß es. Autor Sven Schannak zeigt, wie es trotzdem klappt.

  • Perl-Snapshot

    Größere Dateien tauscht die Jugend heute gerne über den proprietären Dropbox-Service aus. Dessen Web-API erlaubt auch den Einsatz selbst geschriebener Skripte, beispielsweise zum Abholen einer Datei aus dem Schatten einer Firewall.

comments powered by Disqus

Ausgabe 06/2017

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.