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