[MySQL] Limite, Grenzen?

unregiert

abgemeldet
22 April 2006
451
26
Hallo

Ich und ein Kollege tüfteln gerade an einer MySQL Datenbank herum. Sie soll eigentlich ein Archiv mit MD5-Schmetterlingen sein, so dass wir uns früh Gedanken gemacht haben, wie das realisier bar ist. Den ganzen Nachmittag haben wir dann den "ButterflyMaker" programmiert - in C.

Was ich mich aber jetzt frage: Wie viel hält die Datenbank aus? Es ist eine simple Tabellenstruktur, aber sinnvoll gewählt, um Duplikate zu vermeiden.

Code:
  `id` int(11) NOT NULL auto_increment,
  `rain` varchar(255) collate latin1_general_ci NOT NULL,
  `bow` varchar(32) collate latin1_general_ci NOT NULL,
  `stellen` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `rain` (`rain`),
  UNIQUE KEY `bow` (`bow`)

So sieht die Tabelle aus - Die mitlerweile über 2.4 Millionen Einträge hat und damit ca. 240 MB gross ist. Und jetzt die Fragen:
  • Weiss jemand, bis wann die Datenbank halten wird? Heute gab es bereits einen kleinen Crash, den man aber mit der REPAIR Funktion behoben konnte.
  • Gibt es Verbesserungsvorschläge bei der Tabelle? Soll man alles in einer stecken (wie jetzt), oder zwei Tabellen machen?
 
MySql ist doch extra auch große Tabelleninhalte ausgelegt wieso sollte das ein problem darstellen 2,4 mio Inhalte sollten eigentlich kein Thema sein für MySql ich habe bei einem Game inner Stats tabelle zZ ca 1mio Einträge und die läuft prima bis jetzt.

Btw: was sind denn
MD5-Schmetterlingen

und was wird denn genau in den einzelnen Spalten gespeichert? Poste doch mal ein Beispiel dann können mehr mitreden.
 
Verzeichung, dachte, wäre eindeutig.
So sähe die Tabelle aus:
PHP:
id      | 4561
rain    | var
bow     | b2145aac704ce76dbe1ac7adac535b23
stellen | 3
 
Hallo,

ich bastel als Zeitvertreib gerade an einer Soduku Seite. Die Lösungstabelle und Lösungswegtabelle haben z.Z. jeweils ca. 200.000 Einträge. Wobei die eine Tabelle ca. 1,5 GB groß ist. Bisher keine Probleme und auch nur marginale Geschwindigkeitseinbußen bei Abfragen verglichen zu den Anfängen.

MySQL sollte dass schon packen.

Gruß aus Berlin

leller
 
Also bei den Inhalten sehe ich keine Problem allerdings könnte man nochwas am Speicherplatz verbrauch tun. Indem man die Felder besser deklariert. Ich weis ja nicht was bei den einzelnen Felder für maximalwerte stehen.

Die andere Frage ist brauchst du so viele Zeilen?
 
Also bei den Inhalten sehe ich keine Problem allerdings könnte man nochwas am Speicherplatz verbrauch tun. Indem man die Felder besser deklariert. Ich weis ja nicht was bei den einzelnen Felder für maximalwerte stehen.

Die andere Frage ist brauchst du so viele Zeilen?
Es ist eben ein Versucht, die Datenbank zu strapazieren ;) - Und da braucht man so viele Zeilen wie möglich, und das macht unser netter PC neben mir.
Felder deklarieren... Was bedeutet das? Den Typus setzen?
 
Ja zb. bei id is klar wird ein int oder gar big int jenachdem wie hoch die ID zählen muss. Aber bei rain oder stellen das könnte man evtl noch optimieren aber das wird das Kraut nicht fett machen. Ich bin der Meining das da irgendwas schief gelaufen sein muss Bei den Anfragen oder Inserts aber MySql ist für sowas ausgelegt und so eine Tabelle locker packen.
 
Also Anfragen macht es überhaupt keine mehr (bis auf einen Cronjob, der alle 60min die Anzahl der Zeilen & Zeilen pro Stelle zählt), da ich alle INSERTS mit INSERT IGNORE INTO mache.
 
Das einzige, was mir auffällt, wäre eine Optimierung der Spalte stellen. Laut Definition kann rain maximal 255 Stellen lang sein, also ist int(11) bei Stellen ein wenig zu hoch gegriffen - tinyint(3) unsigned ist da passender.

Eventuell lohnt es sich noch, INSERT DELAYED zu verwenden, um der DB ein wenig Freiraum zu geben.
 
Das einzige, was mir auffällt, wäre eine Optimierung der Spalte stellen. Laut Definition kann rain maximal 255 Stellen lang sein, also ist int(11) bei Stellen ein wenig zu hoch gegriffen - tinyint(3) unsigned ist da passender.

Eventuell lohnt es sich noch, INSERT DELAYED zu verwenden, um der DB ein wenig Freiraum zu geben.
Danke für den Tipp. Die Strukturänderungen dauern leider bis jetzt an (selbst mit der Konsolenversion), aber den Funktionstipp werde ich morgen noch umsetzen.

Dauer: 1400 - Status: copy to tmp table... und es läuft und läuft...
ich denke dieser Abschnitt inbesondere der Teil ist für dich sehr interessant
Werde ich mir ebenfalls durchlesen, aber... :yawn:...
 
Zuletzt bearbeitet:
Danke für den Tipp. Die Strukturänderungen dauern leider bis jetzt an (selbst mit der Konsolenversion), aber den Funktionstipp werde ich morgen noch umsetzen.

Dauer: 1400 - Status: copy to tmp table... und es läuft und läuft...

Werde ich mir ebenfalls durchlesen, aber... :yawn:...

Zu tleilax: Baah... seit gestern dauert der Befehl, ohne Änderungen. Habe erst jetzt gelesen, dass er eine temporäre Tabelle zuerst erstellt - Aber bei 300 MiB Tabellengrösse dauert das sehr lang. Ich habe nichts gefunden, wie man es beschleunigen könnte. Kennst du eine Möglichkeit?
Ich ändere die Tabelle gerade' mit ALTER TABLE `one` SET `stellen` `stellen` TINYINT(3) NOT NULL;

Zu strolch00: Hmm, habe die Abfrage ganz unten getätigt, und MySQL gab 0 zurück - Normal?
 
Bow soll den md5-Wert eines Strings beinhalten, oder?
warum nimmst du dann nicht char 32 als datentyp? verbraucht 1 byte weniger und ist zudem schneller, sonst hätte ich nur noch die idee, dass du mittels Partionierung der Datenbank (MySql5) den Bereich einer Select-Anfrage deutlich eingrenzen könntest, z.B. nach dem ersten Char des Rainbows, das wären dann ja im worst-case nur ~1/30 der sonstigen anzahl von zu selectenden Daten.