Wenn man mit größeren Datenmengen und MySQL arbeitet, sollte man die maximal unterstützte Größe einer Datenbanktabelle im entsprechenden Format beachten. Insbesondere Logfile-Tabellen können sonst schnell “voll laufen”, ohne dass dies unmittelbar auffallen muss.
Selbst bei einer Aufteilung der Tabellen in chronologische Häppchen kann die maximale Größe einer Tabelle schnell erreicht sein. Besonders tückisch ist, dass keine Fehlermeldung erscheint, wenn man die Datensätze mit der “delayed”-Option verzögert einfügen lässt. Die Zeilen werden hier unabhängig vom Seitenaufbau zunächst in einen Puffer geschrieben und erst später gesammelt in die Tabelle eingefügt. Das kann den Seitenaufbau zwar deutlich beschleunigen, bietet aber der Skriptsprache keine Möglichkeit mehr einen Fehler zu erkennen.
Bei der Fehleranalyse sollte man daher solche Funktionen deaktivieren, so dass eventuelle Fehler sichtbar werden. In diesem Fall liefert die Datenbank einen entsprechenden Hinweis, wenn die Tabelle voll ist. Ein kleiner Blick in die MySQL-Dokumentation verrät, dass bis Version 5.0.6 Tabellen im Format “MyISAM” standardmäßig nur bis vier Gibibyte möglich sind.
Abhilfe schafft hier der Wechsel auf eine aktuelle MySQL-Version. Ab Version 5.0.6 wurde das Limit auf 256 Tebibyte erhöht. Wer diese Möglichkeit nicht hat, kann über die Systemvariable “myisam_data_pointer_size” den Wert systemweit erhöhen. Ein Bug in der Version 4.1.11 (z.B. Debian Sarge) ignoriert leider diese Einstellung für Tabellen mit dynamischen Zeilen. Weiter helfen auch die Optionen “MAX_ROWS” und “AVG_ROW_LENGTH” für das CREATE-Statement aus dessen Produkt sich die maximale Tabellengröße errechnet.
Generell plädiere ich allerdings dafür die Tabellen so klein wie möglich zu halten. Datensicherungen, Wiederherstellungen und eventuelle Reparaturmaßnahmen gestalten sich dadurch erheblich einfacher und schneller. Bei Protokolltabellen lässt sich dies leicht z.B. anhand des Monats oder der Kalenderwoche auftrennen.
Zur Abfrage solch einzelner Tabellen lassen sich diese dann über einen “UNION” oder über eine “MERGE table” wieder zusammenführen. Für die regelmäßige Abfrage von kumulierten Statistiken setzen wir allerdings aus Gründen der Performance auf Zusammenfassungstabellen die in regelmäßigen Abständen errechnet werden.
1 Reaktion
Sie können hier einen Kommentar hinterlassen, einen Trackback setzen, die Reaktionen per RSS-Feed verfolgen und das Thema für Exciting Commerce Pick!t vorschlagen.Kommentar schreiben