Die Datenbank, das unbekannte Wesen Teil IV

Der Datenbank-Update

Alles wäre so schön mit diesen Datenbanken, wenn es den Update also das Einfügen, Abändern und Löschen nicht gäbe!

Gerade letztens habe ich ein Programm gesehen, das eigene Seiten mit Datenbankunterstützung betrieb. Dabei wurden von diesem Programm auch Daten erfasst und diese auf eine Blog-Datenbank übertragen. Es wurde gezwungenermaßen bestimmt, dass man 2 Datenbanken halten müsse.

Na und, fragen Sie! Macht doch nix, oder?

Schauen wir uns doch mal einen Update auf einen Tabellensatz an. Da werden also Daten in die Tabelle geschrieben. Jetzt hat die Datenbank aber in ihren Tabellen, ggf. auch Indizes definiert. Was muss die Datenbank machen?

Sie muss zum Zeitpunkt des Schreibens zunächst alle Threads, die sich auf auf diese Tabelle beziehen stoppen. Warum? Nun, stellen Sie sich vor, sie wollen alle Sätze aus der Tabelle xy lesen. Parallel dazu verändert jemand einen Satz, den Sie schon gelesen haben, Sie erhalten also nicht mehr aktuelle Daten. Das geht doch nicht an, oder? Deshalb muss beim Schreiben der Thread gestoppt werden.

Eigentlich müsste man nicht die Lese-Threads stoppen, sondern man müsste die Tabelle solange sperren, bis der Update durch ist. Erst dann darf wieder gelesen werden. Was aber, wenn beim Schreiben ein Fehler passiert? Bleibt die Tabelle dann gesperrt für alle?

Es gibt Datenbanken, die derartiges machen. Die Tabelle bleibt gesperrt. Somit tummeln sich dann alle Lesenden solange im Wartezustand, bis die Tabelle wieder frei ist. Bei anderen Datenbanken wird der sog. Dirty Read unterstützt. D.h. Sie können gegen einen Update lesen. Bei dem Satz, der gerade geschrieben wird, ist der Satz gesperrt und es können andere Sätze gelesen werden. Trifft die Leseroutine auf den gesperrten Satz, so wartet sie kurz bis der Satz wieder frei ist. Damit ist aber nicht gesichert, dass Sie immer die richtigen Sätze gelesen haben, denn schon gelesene können in der nächsten Sekunde geändert sein. Bei der Programmierung müssen Sie sich dessen immer bewusst sein, dass Sie nur eine Momentaufnahme haben.

Eigentlich dürften in MySQL für die normale Definition als MYISAM-Tabellen gar kein Update erlaubt werden. Denn auf der Datenbank sollte immer ein konsistenter Zustand herrschen.

Aber kommen wir nochmals auf das Schreiben zurück!

Was macht eine Datenbank beim Schreiben? Sie müssen hier die einzelnen Schreibmöglichkeiten unterscheiden: Es gibt das Abändern eines bestehenden Satzes, das neu Einfügen eines neuen Satzes und das Löschen eines Satzes in einer Tabelle.

Mit dem Schreiben eines Satzes ist es aber nicht getan, denn eine Datenbank lebt – im Gegensatz zu einer Datei – davon, dass sog. Indiezes gebaut werden. Und genau dies ist ein erheblicher Aufwand, den die Datenbank machen muss. Dabei stellt sich das Einfügen eines neuen Satzes – also der insert als die am aufwendigste Update-Art heraus.

Der Datenbank-Index

Was um Himmels Willen ist jetzt aber ein Index?
Man sagt auch – hochgestochen – ein Index ist die Inverse eines Feldes in einer Tabelle! Aber lassen wir das Hochgestochene! Stellen Sie sich vor, Sie schreiben einen Satz in eine Tabelle, wo Sie Adressdaten gespeichert haben. Sie haben 1 Mio. Adressdaten. Sie wollen später mal herausfinden, wer unter dieser Million Personendaten in – sagen wir – Bonn wohnt.

Mahlzeit! Sie müssen, um diese Personen zu finden, ein Programm schreiben, das von Satz 1 beginnt und bis zum Satz 1.000.000 alle Sätze durchläuft und eine Abfrage macht, die den Inhalt des Feldes Ort mit dem Wert Bonn vergleicht. Haben Sie einen Satz gefunden, bauen Sie eine 2. Liste auf und speichern den ganzen Tabellensatz da hinein! Nehmen Sie weiter an, der Tabelleninhalt ist nun gerade umgekehrt sortiert: „Ort Bonn steht ganz unten!“ Dann müssen Sie doch fast eine Million Vergleiche machen und fast eine Million Sätze lesen! Das kann dauern! bei unsortierten Tabellen sagt man, dass man so im Mittel immer die halbe Tabelle durchsuchen muss.

Jetzt nehmen Sie an, Sie haben diese Suchanfrage vorausgesehen und haben neben den Sätzen mit den Adressdaten noch eine Datei erzeugt, wo sie sich für jeden Satz mit dem Ort die Nummer des Satzes in der anderen Datei gemerkt haben! Sie haben sich in der 2. Datei also für alle Orte immer die Satznummer des Originalsatzes in der Adressdatei gemerkt. Wenn ein Ort 2 oder 3 mal vor kam, haben Sie hinter dem Ort Bonn in der 2. Datei sich die jeweilige Satznummer gemerkt!

Sie wissen mit der 2. Datei also, dass der Ort Bonn in 53 Sätzen in der Originaldatei vorkommt. Jetzt brauchen Sie nur die 2. Datei nach Bonn zu durchsuchen, und schon haben Sie alle Satznummern der Originaldatei mit Ort = Bonn! Die 2. Datei ist ergo nur dann gleichgroß wie die Originaldatei, wenn alle Personen in unterschiedlichen Städten wohnen würden. Ist wohl nicht so arg realistisch. Also ist die 2. Datei viel kleiner – hat weniger Sätze! Sie müssen, wenn Sie die 2. Datei nach Bonn durchsuchen, viel weniger Sätze lesen, das erspart Ihnen enorm viel Zeit!

Diese 2. Datei nennt man auch einen Index der Adressdatei für das Feld Ort! So einen ähnlichen Index baut die Datenbank für Sie auf, immer wenn Sie Sätze in die Datenbank einfügen. Eine Suche ist dann in der Datenbank um so schneller, wenn Sie als Suchfelder derartige indizierte Felder aufbauen.

Genau das unterscheidet grob gesagt eine Datenbank von einer Datei! Für den Index gibt es in der Informatik einige ausgeklügelte Verfahren, wie man diesen erstellt und sehr schnell darin suchen kann.

Bleibt aber zu erwähnen, dass dieser Index bei allen Schreiboperationen auf der Datenbank Änderungen unterliegt. Was wiederum bedeutet, dass bei allen Updates auf eine Datenbank, immer der Satz selbst geschrieben werden muss und dann noch der Index der Tabelle angepasst werden muss!

Jetzt stellen Sie sich vor Sie suchen nach Bonn! Und ich ändere für eine Person, die mal in Bonn wohnte gerade den Ort in Berlin! Jetzt haben wir einen Konflikt! Sie haben den Satz schon gelesen und also die Person für den Ort Bonn gefunden! Oder sie haben den Satz noch nicht gefunden und erhalten dann die Person als in Berlin lebend! Was ist jetzt richtig? Was soll die Datenbank tun? Auf der einen Seite liest jemand und parallel dazu schreibt einer!

Viel schlimmer wäre der Fall, dass Sie parallel zu mir lesen und ich schreibe, die Datenbank den Index ändern will und einen Fehler bekommt, weil z.B. kein Platz mehr in den Dateien ist? Datei voll! Was erhalten Sie? Was passiert mit dem Ort in der Datei und dem Index? Was soll die Datenbank tun?

Ich lasse das Problem einmal vorerst offen! Denn dazu brauchen wir noch einen Datenbankbegriff, der noch nicht eingeführt ist.

Ganz oben berichtigte ich von dem Programm, wo in einer Datenbank eine Änderung gemacht wurde und diese auch in einer anderen Datenbank gemacht werden sollte! Das ist doch in der Fehlersituation „Datei voll“ auf der 2. Datenbank noch schlimmer, oder? Die 1. Datenbank ist geändert, die 2. aber noch nicht! Was gilt jetzt!

In beiden Fällen haben wir einen sog. Schiefstand unserer Daten! Oh Wehe!

Wie diese Problematik gelöst werden kann, werde ich Ihnen im nächsten Artikel berichten! Fortsetzung folgt 🙂

Bernd Klüppelberg

Hier noch alle Links auf die Artitkelserie (soweit sie veröffentlicht ist):
Die Datenbank, das unbekannte Wesen Teil I
Die Datenbank, das unbekannte Wesen Teil II
Die Datenbank, das unbekannte Wesen Teil III
Die Datenbank, das unbekannte Wesen Teil v
Die Datenbank, das unbekannte Wesen Teil VI

Bisher gibt es keinen Kommentar. Schreiben Sie einen Kommentar!

Schreibe einen Kommentar