Datenbanken sollen große Datenmengen möglichst performant verwalten – so wie die Theorie. Wie das ganze in der Praxis aussieht wollte ich einfach mal testen. Da das ganze noch einen kleinen Sinn ergeben soll gabs folgende Testaufgabe:

Alle Zeichenkombinationen (a-z,A-Z,0-9,paar ausgewählte Sonderzeichen) als Klartext und deren MD5-Hash in die DB speichern.

Dazu erst mal folgende Hardware aus der Gerümpelkiste geholt:

• P4 @ 1,6 GHz
• 512MB SD 133
• 3x40GB IDE HDD @ 7200 im RAID 0

Als OS einfach nur das aktuelle Knoppix gekrallt, MySQL 5 und PHP 5.2.0.8 erledigen den Rest. Die Strings werden durch ein kleines PHP-Script generiert und per mysqli an die DB gesendet. Auf diesem Weg konnte ich im ersten Test über 60Mio Strings erzeugen. Inzwischen habe ich nach einem weiteren ~12h-Testlauf folgende Werte:

• Anzahl Einträge lt. phpMyAdmin: 6.678.400
• Größe laut pma: ~100MB

Das scheint aber nich ganz zu stimmen, denn:

• Größe des MySQL-Verzeichnis: 718MB
• Hashes weiter hinten in meiner String-Liste werden als Duplicate gemeldet, tauchen mit SELECT aber nicht auf

Ich schätze mal, dass der Rest noch in irgendeinem Cache verschwunden ist – so groß sollten die Indezes normal nicht sein. Momentan läuft ein Cache-Flush und danach Repair/Optimize. Mal schaun, was morgen rauskommt. Hier noch ein paar Beobachtungen:

• In den ersten Sekunden wurden fast 2000 Hashes pro Sekunde gespeichert
• Nach ca .20 Sek war der Puffer wohl voll und die Performance ging in den Keller
• Limitierender Faktor war nicht wie vermutet die CPU sonden (wie es auf den ersten Blick aussieht) die Festplatten – trotz RAID0. DMA ist zwar an, dennoch hängt MySQL mit ziemlich viel IO-Wait rum

In nächster Zeit werde ich so mal testen welche Zugriffsoptionen, Dateisysteme, Hardwarekombinationen, … sich am besten für große Datenbanken eignen.

[Update]

Momentan läuft das ganze mal mit einer CSV als Ausgabeort – Ergebns nach einer Stunde:

• Hashes berechnet: 86.697.973
• Dateigröße: 3GB
• Hashes / Sekunde: ~ 24.000