Mailinglisten-Archive |
> Ich habe die Aufgabe, 15 Mio. Datensätze, bestehend > aus einer ID und zwei md5-Strings, in MySQL zu speichern. Nachher > soll ein kleines PHP-Script einen md5-String vorgelegt bekommen > und danach in md5_1 suchen. Wenn gefunden, den kompletten > Datensatz ausgeben. > > Ausgedacht habe ich mir folgende DB-Struktur: > > id, int, auto_increment, index > md5_1, char(32), index > md5_2, char(32) > > Frage: Gibt es eine noch schnellere Möglichkeit? > > Nun habe ich mal 5 Mio. Datensätze generiert, ein Optimize Table > drüberlaufen lassen und einen Testselect durchgeführt. Gedauert > hat das ganze ca. 5 Sekunden. Für einen Webservice eigentlich > viel zu langsam, der möglichst viele Requests bewältigen soll. wieso machst Du auf den md5_1 keinen unique index? Deine Beschreibung klingt so als wäre das auch möglich. Was ist es denn derzeit für ein Rechner? > > Nun habe ich mir überlegt, die Tabellen so aufzusplitten, dass > die Datensätze nach ihrem ersten Zeichen in verschiedene Tabellen > abgelegt werden: Alle md5-Strings, die mit a beginnen, in tb_a, > alle, die mit b beginnen, in tb_b usw. Das würde 36 Tabellen > herausbringen (26 Zeichen des Alphabets plus die Ziffern 0-9). das hatten wir hier kürzlich schon mal, das bringt kaum was, das ist bei einem index vielleicht bestenfalls 1 lesezugriff weniger verwendet er den index denn? (mach mal ein explain select... ) > Und noch eine Frage: Welche Rolle spielt die Hardware? Um SCSI > würde man wohl kaum herumkommen, was bringt in dieser > Beziehung ein Dualprozessor-System, was bringt ein PIV > Xeon-Prozessor? Respektive: Was bringt MySQL richtig auf trab und > was würde sich lohnen? > keine Ahnung, aber die Empfehlung von MySQL möglichst Reiserfs zu verwenden kennst Du? Du kannst auch z.B. mit InnoDB die Datenbank auf mehrere Partitionen splitten, das kann Dir später wenn mehr als eine Anfrage gleichzeitig kommt helfen. -- Mike Beck mike.beck_(at)_users.sourceforge.net
php::bar PHP Wiki - Listenarchive