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".
|
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.
| Whitepaper |
|---|
|
The Role of Open Source in Data Integration
Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)
Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
Andreas W.,
23.11.2010 23:56
sinseq,
11.10.2009 17:46
Martin,
07.10.2009 23:48
Und ganz im Ernst: Der Seitenaufbau der genannten Tauschseite ist echt langsam! Und dann wurde bei den Bildern nicht mal ihre Größe angegeben, so dass zu Problemen beim Rendering kommt.
Das Ego des Autors in allen Ehren - aber so kann und sollte (!) das in KEINEM Fall in der Praxis eingesetzt werden!