Hallo Leute,

ich spiele gerade mit einer MySQL-Datenbank herum und weiß nicht so
recht, wo die Leistungsgrenzen bei MySQL liegen. Ich möchte das gerne
an einer Beispieltabelle aufzeigen:



In diese Tabelle sollen Statistiken verschiedener Hosts geschrieben werden
und genau da liegt mein Problem. Jetzt habe ich beispielsweise 30 Hosts,
die ihre Auslastung alle 15 Sekunden in diese Tabelle schreiben.
Die Tabelle wächst also in Zeilen pro

Tag   =   172.800
Woche = 1.209.600
Monat = 5.184.000

Anders sieht es schon aus, wenn zum Beispiel ein ISP 5000 Server hat.

Tag   =   1.200.000
Woche =  28.800.000
Monat = 864.000.000

Und das ist noch nicht alles, denn 5000 Server ist noch relativ wenig.
Hinzu kommt, dass der Schreibinterval geringer aber auch höher sein
kann. Für meine Planung möchte ich gerne von diesen Zahlen ausgehen.

Wie baue ich nun am besten die Tabellenstruktur? In meinem alten Schema
hatte ich alles ohne Datenbank realisiert und für jeden Tag eine neue
Datei erstellt, das würde ich aber hier für zu aufwendig halten. Wäre eine
Tabelle für jeden Server besser, also ProcStats_Servername oder
doch lieber ProcStats_Servername_Datum um die Anzahl Zeilen
pro Tabelle zu verringern? Oder soll ich es genau so belassen, wie es im
Moment ist? Ich möchte an dieser Stelle noch einwerfen, dass ich andere
Tabellen habe, wo für jedes Netzwerkdevice eine Zeile geschrieben wird.

Für Hilfe wäre ich super dankbar.

Greez,
opi\n\n

<!--EDIT|opi|1147693503-->

Mir sind gerade noch andere Möglichkeiten eingefallen:

- eigene Datenbank für jeden Server
- eigener Benutzer für jeden Server in der gleichen DB

Nur kann man Tabellenjoins über Datenbankebene ausführen?
Können Benutzer ihre eigenen Tabellen in einer DB unter MySQL besitzen?

Du solltest Dir überlegen, wie die Queries ausfallen. Wenn Du alles zusammen abfragen willst, wäre eine Tabelle besser, da joins relativ aufwändig sind. Wenn der Großteil der Abfragen nach Servern und/oder Datum getrennt ist, würde ich getrennte Tabellen machen...

[quote=renee,15.05.2006, 13:56]Du solltest Dir überlegen, wie die Queries ausfallen.[/quote]
Nun, es schaut ja so aus, dass wenn man sich die Auslastung eines Servers
ansehen möchte, man den aktuellen Zeitpunkt nimmt, eventuell die letzten
30 Minuten. Wenn natürlich jemand um 00:15 drauf schaut, sieht er
entweder nur die letzten 15 Minuten, oder es kommt ein Join. Wenn aber
alles in einer Tabelle ist, brauche ich das nicht, stimmt.

Die Frage ist nur, ob MySQL nicht irgendwann die Luft ausgeht, bei 800Mio
Zeilen...

[quote=opi,15.05.2006, 14:01]Die Frage ist nur, ob MySQL nicht irgendwann die Luft ausgeht, bei 800Mio
Zeilen...[/quote]
bei 4 Netzwerkdevices eth0, eth1, lo, dsl0 sind das schon 3.200 Mio Zeilen

Vielleicht ist ein Teil der Dokumentation ganz interessant!

@renee, jo, die max. Tabellenbegrenzung hatte mir zu Anfang die meisten
Kopfschmerzen bereitet, aber darüber mache ich mir nun keine Gedanken
mehr, denn jede Tabelle erhält einen eigenen Tablespace und das sollte
reichen.

Aber ich habe leider keine Erfahrungen, was die Leistung der MySQL-
Datenbank betrifft. Vielleicht sollte ich das ganze Verfahren mal simulieren,
5000 Prozesse starten, die in die Datenbank schreiben und dann noch die
HTTP-Requests + SQL-Selects auf die Antwortzeiten überprüfen.

Viel, viel arbeit also! Ob das mein Notebook hergibt :)

ich kann dir leider keine erfahrungswerte liefern, zumindest nicht mit
vielen einträgen.
aber wir haben hier eine db mit ca. 1 mio. einträgen und >90 feldern, also
eine sehr breite tabelle. die ist glaube ich so 500MB groß. das klappt prima.

Ich bin mit MySQL und massiver Logdatenverarbeitung nicht zufrieden. Ich habe das Gefühl, dass der Optimizer von MySQL nicht optimal genug arbeitet. Außerdem scheint eine einfache Aufgabe wie "einen Cursor auf die nächste Position bringen" nicht effizient zu lösen sein. Und wehe, du überschreitest eine Grenze, z.B. von 32Bit auf 64Bit: zwar kann man MySQL beibringen, auch mit größeren Pointern zuarbeiten, aber das erfoderliche ALTER TABLE wird Tage dauern. Besser wäre vielleicht folgender Ansatz: nur der letzte Monat (oder Woche oder Tag) wird in einer Datenbank gehalten. Alles, was älter ist, wird in gzippte Textdateien gedumpt und weggeschrieben. Vorher macht man noch interessante statistische Auswertungen über diese Daten. Oder man benutzt andere DB-Engines, aber da habe ich keine Erfahrung.

[quote=ptk,15.05.2006, 20:56]Vorher macht man noch interessante statistische Auswertungen über diese Daten.[/quote]
das war mein gedanke, dass man für einen gesamten monat eine aus-
wertung fährt. aber das mit dem dump find ich nicht schlecht.

eine art archivierung fänd ich ebenfalls nicht schlecht. alles was älter als
eine woche ist kommt in die archivtabellen, die den gleichen aufbau haben,
nur eben archiv_irgendwas heißen. ein anderer prozess löscht dann täglich
die daten, welche die aufbewahrungszeit überschreiten. das ist alles nicht
so einfach!

ich bastel seit gestern an einem passenden db-model mit allem drum und
dran... sessions, users, groups, thresholds, mailgroups, alerts... es bereitet
mir echte kopfschmerzen.\n\n

<!--EDIT|opi|1147769963-->