Die Datenbank, das unbekannte Wesen Teil VI

Auswirkungen auf den Datenbankbetrieb

im Teil V wo es um Transaktionen ging, sind einige Umstände zu Tage getreten, die Sie vielleicht nicht so vermutet hätten. In diesem Teil soll es um die Auswirkungen gehen.

Blog-Admin

Wie leicht ist es doch, mehrere Blog-Artikel im Admin-Bereich des WordPress aufzuschlagen. Oft ist man ja geradezu gezwungen dies zu tun, weil man aus einem anderen Artikel etwas heraus kopieren möchte. Doch Vorsicht, ich würde jedem raten, zur gleichen Zeit immer nur einen an den Admin-Bereich zu lassen. Denn wenn mehrere dies tun, kann es bei der Fülle der unterschiedlichen Updates auf die Datenbanken ggf. zu Schwierigkeiten kommen. Denn die Tabellen des WordPress arbeiten nicht transaktionsgesteuert.

Zugegeben dieses Beispiel ist wohl nicht derart praxisnah, weil es doch wohl wenige Blogs gibt die mehrere Benutzer gleichzeitig definiert haben! Ich meine die „Redakteure“. Selbst mehrere Admin-Bereiche offen zu haben und daraus zu kopieren, dürfte kein Problem sein, da der eine nur liest, und der andere liest und schreibt. Außerdem wird das nicht gleichzeitig geschehen. So schnell sind wir mit unseren Fingern noch nicht.

Was ist mit dem Kommentar-Schreiben? Hier kann es zu zeitlichen Überlappungen kommen. Doch wird hier das Betriebssystem und der Server die Anforderungen 2-er gleichzeitiger Klicks auf den Absende-Button des Kommentars für Serialisierung sorgen, und bei schneller Datenbank sollte hier also nichts passieren können. Wenn der Server aber schwach und die Datenbank lahm ist, dann könnte es schon zu Verzögerungen kommen, die aber durch die Serialisierung gesichert sein dürften. Es sei denn Sie verlieren die Geduld und klicken trotzdem wild herum, dann werden ja immer neue Aufträge gemacht, die ggf. nur Teile der Daten besitzen, dann kann es zu Lesefehlern kommen.

Eigene Seiten

Bei eigenen Seiten, die man mit Datenbankunterstützung programmiert, ist allerdings Vorsicht geboten. Was kann hier passieren? Lassen Sie mich das an einem Beispiel verdeutlichen:

Sie programmieren in PHP und damit sind sie gezwungen, die Anwendung so zu schreiben, dass alle Eingabedaten aus Formularen mit einem Button übertragen werden. Natürlich können Sie all das mit Javascript auffangen und nur einmal übertragen lassen! Doch setzt das ein hohes Maß an Javascript-Erfahrung voraus. Sie können auch asynchron mit Ajax und Javascript Abfragen realisieren und im Javascript ausgeben, dann müssen Sie aber sicheres Ajax und Javascript schreiben können.

Bleiben wir also bei PHP und verstecken unsere Logik auf dem Server! Hier haben wir schnell 2 – 3 Bildschirme, die erfasst werden müssen. Die Logik ist deshalb auf die 2-3 Einzelseiten verteilt, weil Sie zwischendrin immer Auswahldaten erhalten. Beispiel: Ein Formular, das mehrere Alternativen abfrägt und dann deren Inhalte anzeigt. Sie müssen die Alternative abfragen, dieses Formular absenden, dann kommt das 2.Formular mit der eingegeben Alternative etc. Wenn jetzt Updates auf die Datenbank laufen, sind Sie eigentlich gezwungen eine Transaktion zu bauen.

Oder?

Im Wissen, dass Sie keine transaktionsfähige Datenbank im Hintergrund haben, sollten Sie mit PHP-Mitteln die Daten zwischenspeichern und nur bei dem letzten Alternativformular die Daten abspeichern. Manchmal sehen Sie auf den Webseiten Dinge wie Eingabeformulare und dann eine Übersicht mit den Funktionen „alles richtig, speichern“ oder „zurück“. Hier ist genau der Datenbankfähigkeit Rechnung getragen worden.

Durch Änderung der Bildschirmabfolge wurde erreicht, dass man nicht über einen Bildschirmwechsel eine Transaktion halten muss. Beim Schreiben, das ggf. auf mehrere Tabellen geht, kann man sich ja mit Sperren auf die Tabellen absichern, aber die Transaktionsprogrammierung hat man vermieden.[Für die PHP’ler unter Ihnen sei gesagt, dass die Zwischenspeicherung der Bildschirme über PHP-Sessions machbar ist.]

Also erst alle Daten aller Bildschirme (Formulare) zwischenspeichern, dann entscheiden, welche Tabellen betroffen sind und diese dann sperren. Danach erfolgt das Schreiben auf alle Tabellen, und die Entsperrung der Tabellen. Wenn nur auf eine Tabelle geschrieben wird, dann reicht die sog. Satzsperrung der Datenbank MySQL völlig aus, da sie datenbank-intern serialisiert läuft.

Vermeiden Sie auf alle Fälle Updates auf mehrere Datenbanken, da MySql kein 2-face-commit kennt. Und wenn man sowas doch braucht? Vielleicht wäre es eine Möglichkeit von Datenbank 2 in Datenbank 1 das Feld lesen zu lassen und selbst den Update in Datenbank 2 zu machen, falls das geht und man das Programm mit Datenbank 2 verändern kann! Eine weitere Möglichkeit wäre, einen Prozess zu starten [für PHP’ler: PHP als Prozess starten mit #!/usr/bin/php und Php als Programm mit Kommandozeilen starten], der das Feld in der Datenbank 2 einstellt. Gibt es dabei Fehler, kann man den Update durch Speicherung auf z.B. eine Textdatei wiederholen. Der Job (der Prozess) würde dann erst die Textdatei(en) lesen und dann die Updates machen, ist einer ok, markiert er den Satz in der Textdatei. Diese Textdateien, müssen allerdings serialisiert verarbeitet werden, d.h. nur dieser Job darf an die Dateien, kein anderer!

Schnelligkeit der Datenbank

Haben Sie sich eigentlich schon mal um Ihre Blog-Datenbank gekümmert? Gut, ich hoffe Sie haben sie öfters mal gesichert! Nein? Nun, dann wird es aber Zeit! Als Blogbetreiber sollten sie immer eine aktuelle Version der Datenbank auf Ihrem Rechner und auf dem Web haben.

Haben Sie das Gefühl, dass die Datenbank früher mal schneller lief? Heute ist sie irgendwie langsamer geworden? Das kann daher kommen, dass logisch aufeinander folgende Sätze zu weit auseinander stehen. Dies kann dadurch zustande kommen, weil viele Tabellen eine ID als auto_increment definiert haben. Die Tabelle ist nach der Reihenfolge der ID (meist Primärschlüssel) geordnet. Der logische Zugriff geht aber eine andere Reihenfolge durch die Tabelle.

Es kann sein, das der 1. gelesene Satz ganz unten in der Tabelle steht, der 2. Satz wieder ganz oben und so weiter. Die Datenbank muss also andauernd in der Tabelle herumhüpfen. Da hinter diesem Lesen ggf. auch wirkliche Zugriffe auf die Platte stehen, kann es zu Verzögerungen kommen. Ein guter Server schafft Operationen im Hauptspeicher (Puffer) im Nanosekunden Bereich also 0,000 000 001 Sek. Während heutige Platten Zugriffe nur im Mikrosekunden Bereich (0,000 001 Sek.) schaffen. Das ist ein Faktor von 1000. Also immer wenn die Datenbank wirklich auf die Platte muss, dauert es um den Faktor 1000 länger, bis ein Satz gelesen ist.

Was kann man dagegen tun? Man kann, wenn es die Struktur erlaubt (keine Textfelder), die Tabelle in Excel exportieren, dort Zusammengehöriges zusammen sortieren und wieder hochladen. Wenn Sie z.B. eine Personentabelle wie eine Adresstabelle sequentiell einlesen sortiert nach Nachname, dann wäre es sinnvoll, wenn die Tabelle in der Reihenfolge Nachname gespeichert wäre. Der ID-Auto-Increment-Schlüssel würde dann in der Reihenfolge Nachname beim Hochladen aus Excel definiert und die Tabelle wird schneller, da die Datenbank immer ganze Blöcke von der physikalischen Datei liest und somit mit einmal auf Platte gehen, gleich mehrere Sätze liest. [Das auf Platte gehen bzw. von Platte lesen nennt man auch I/O (Ein-/Ausgabeoperation , input-/output operation)]. Je mehr I/O’s Sie vermeiden, um so schneller ist die Datenbank.

Im Blog gibt es zur Verschnellerung auch sog. Cache-Speicher-Plugins, die aber nur dann etwas nutzen, wenn die Satzabfolge in der Tabelle auch gut sortiert ist. Eine derartige Umsortierung nennt man auch Reorganisation der Datenbanktabellen.

Aber gemach gemach! Diese Reorganisationen sind nur dann sinnvoll, wenn die mehrere 10.000 Sätze in einer Tabelle haben. Ich glaube sogar, dass sich dann auch erst ein Cache-Speicher lohnt. Denn die Krux an guten Algorithmen in der Informatik ist, dass sie auch kontraproduktiv sein können. Für viele Algorithmen gibt es ggf. Angaben, bei welcher Anzahl an Sätzen sie lohnenswert sind. Bleibt man unter diesen Grenzen, dann kann die Laufzeit auch steigen:

Beispiel

Es gibt etliche Möglichkeiten Zahlen und / oder Texte in einer Datei zu sortieren. Eine der einfachsten und verständlichsten Methoden ist der sog. bubble sort [siehe bei Wikipedia]. Man nimmt sich die erste Zahl und geht damit durch alle Sätze. Dabei vergleicht man, ob diese Zahl größer, gleich oder kleiner als die 1. Zahl ist. Wenn sie größer ist, dann vertauscht man die gefundene Zahl mit der festgehaltenen. Das macht man mit jeder Zahl von 1 bi n! Am Ende sind die Zahlen sortiert.
Daneben gibt es den sog. Binär-Sort (Quicksort). Hier nimmt teilt man die Liste aller Zahlen in 2 Bereiche. Man nimmt aus der 2. Liste die vorletzte Zahl und prüft diese mit der 1. Liste. Bei Größer vertauscht man die kleinere Zahl mit der festgehaltenen. Dann teilt man die Listen wieder und vergleicht. Am Ende hat man dann sortierte Teillisten, die sortiert sind. Dieser Binär-Sort [siehe auch bei Wikipedia] ist um vieles schneller, als der Bubble Sort, aber er lohnt sich erst bei Datenmengen von größer 100 Sätzen! Es lohnt sich also 2 Suchen zu programmieren, eine unter 100 Datensätze und eine darüber! Der Zeitunterschied kann enorm sein.

 

Um es ähnlich Dr. Wolf (Hund-Katze-Maus) zu sagen: „Sie sehen, unsere Datenbank hat viele Geheimnisse!“

Ich hoffe, Sie mit dieser Artikelserie ein wenig näher an das unbekannte Wesen Datenbank herangeführt zu haben; Sie jetzt die Tätigkeit einer Datenbank, des Betriebssystems und den Server ein wenig besser verstehen.

Wenn Sie jetzt sagen: „Alles Quark, die wissen schon, was sie tun“, dann gebe ich zu bedenken, dass sehr große Systeme wie z.B. das SAP®-System nur eine Datenbank / System betreibt, die über 10 TB groß sein kann! Und mit solchen weltweit verbreiteten Systemen alle betriebswirtschaftlichen Aufgaben von Unternehmungen gesteuert werden können! Jedes SAP R/3®-System besitzt aber immer nur eine Datenbank mit 80.000 – 100.000 Tabellen! Warum nur eine? Weil ein Datenverlust bei einer solchen Datenbank, die alle Unternehmensdaten beinhaltet, eine Katastrophe wäre. Bisher ist es noch nicht wirtschaftlich, eine verteilte Datenbank (mit two face commit) zu betreiben.

Dies war ist das (vorläufige) Ende dieser Artikelserie über Datenbanken.

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 IV
Die Datenbank, das unbekannte Wesen Teil v

Bisher gibt es keinen Kommentar. Schreiben Sie einen Kommentar!

Schreibe einen Kommentar