Wir sind heute mit unserer neuen Schulwebsite online gegangen. Eine MySQL-Tabelle bekommt ständig neue Einträge. Wieviele Datensätze kann eine MySQL-Tabelle verkraften? Geht der Server deswegen irgendwann in die Knie?

Naja, das kommt auf den Server (=Computer) drauf an, und weiterhin kommt es auf die
Datensatzgröße an.

Was kommt den pro Minute/Sekunde/Tag so dazu an Daten?
Und was ist den die durchschnittliche Zeilengröße?

Ich kenn mich mit MySQL speziell nicht aus, aber ein paar hundert Millionen Datensätze wird so eine DB schon verkraften. Wichtig sind Indexe und ein DB-Design, das sich an der 3.Normalform orientiert.

Hier gilt ausnahmsweise nicht 'The Sky is the Limit' sondern 'The Disc is the Limit'.

Naja, nicht nur The Disc, sondern auch The CPU

Ne 2TB-Platte bringt nix, wenn die CPU bei der Masse an Anfragen nicht mehr dazu kommt, Antworten zu geben.

Auch ist ne schnelle RAM-Anbindung empfehlenswert: Meine 1,5GB DDR2-RAM laufen mit 400MHz effektiv mit nem Durchsatz um die 350MB\s für MySQL (mein alter Heim-PC, der auch als Datenbank-Server dient) ... Damit gehen dann auch kartesiche Produkte (über 2 Tabellen) auf 40000 Datensätze umfassendende Tabellen in rund ner Minute zu berechnen (Ich weiß, das macht man nicht , aber es geht trotzdem )

Direkt zum Absturz bekommt man MySQL nur mit persistenten Verbindungen bzw. wenn der TCP-Stack des Betriebssystems eh schon dicht gemacht hat.

Ferner gilt: lieber viele kleine Anfragen, als eine große: MySQL behandelt 70000 1-Datensatz-Inserts SCHNELLER als 6 INSERT-Befehle für die gleiche Datenbmenge. Je kürzer also der Insert-Befehl, desto besser (wobei man zu einem gewissen Maße mehrere Datensätze mit einem Befehl behandeln sollte ) Das muss man aber im Einzelfall ausprobieren ^^

Hab selber grad n Projekt gehabt, wo ich besagte ~70000 Datensätze in möglichst kurzer Zeit (vor'm PHP-Timeout von 30 Sekunden) in der DB haben musste (generiert aus nem XML-File mit ~3000 Datensätzen). Laufzeiten liegen da bei etwa 26 Sekunden in meiner Version (incl. 16 Sekunden zum Übertragen des XML-Files über ne DSL-Light-Leitung).

Außerdem, was MySQL nicht mag:
- GROSSE Queries mit vielen Antwort-Datensätzen
- Abfragen auf mehr als 5 größere Tabellen (Produkt der Datensatzzahlen >2Mrd) (führt zwar nicht zum Absturz, aber doch zu erheblichen Antwort-Zeiten)
- Kreuzabfragen auf die gleiche Tabelle
- Tabellen ohne Indizes (zumindest ein PK sollte gesetzt sein; besser noch mehrere UKs ausgehend von häufig genutzten Abfragespalten, normale IKs gehen zur Not genauso).
- LIKE-Abfragen auf Tabellen mit fehlende Fulltext-Key (Sollte klar sein, warum )

Wenn man grob diese Regeln beachtet, bekommt man eigentlich MEIST bei einer korrekten Abfrage auch ein korrektes Ergebnis

Naja. Sei denn man versucht auf ne Tabelle mit Doppelten Datensätzen und mehreren tausend Einträgen nen Unique-Key zu setzen ... Aber das ist ne andre Geschichte. (Resultat war, dass der MySQL-Server ohne Angabe einer Fehlermeldung den Befehl nicht ausgeführt hat).

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Naja, nicht nur The Disc, sondern auch The CPU Ne 2TB-Platte bringt nix, wenn die CPU bei der Masse an Anfragen nicht mehr dazu kommt, Antworten zu geben.

Die ursprüngliche Frage lautete aber doch:

Marco D. hat folgendes geschrieben:

Wieviele Datensätze kann eine MySQL-Tabelle verkraften? Geht der Server deswegen irgendwann in die Knie?

Und das hat dann nun mit ner CPU nichts zu tun. Wir hatten bis vor kurzem einen SQL-SErver auf einem 166MHZ-PC mit 4GB Daten am Laufen, der in einer Produktionsumgebung lief. Hier merkte man sehr wohl, welche Abfragen über Indexe liefen, und welche nicht.

Dem Rest deiner Ausführungen entnehme ich, das man MySQL nicht verwenden sollte, die Einschränkungen sind doch einfach zu groß.

Man darf nicht vergessen, das eine gute DB mit wohl durchdacht gesetzen Indexen eine CPU nicht sonderlich belastet (ausgenommen Aggregate), da der Aufwand pro Datensatz O(1) ist. Mit anderen Worten: Das Suchen in einer Tabelle mit 100.000.000 Datensätzen dauert genauso lang, wie in einer Tabelle mit 10 Datensätzen. (Na gut: fast). Dies hat u.A. damit zu tun, das in einer realen Umgebung von den 100.000.000 Datensätzen maximal 1% gerade aktuell, d.h. im Cache gehalten werden.

Das MySQL so viele Caveats besitzt, ist angesichts der Versionsnummer ein Armutszeugnis und disqualifiziert sie eigentlich für ernstzunehmende Anwendungen.

alzaimar hat folgendes geschrieben:

BenBE hat folgendes geschrieben: Naja, nicht nur The Disc, sondern auch The CPU Ne 2TB-Platte bringt nix, wenn die CPU bei der Masse an Anfragen nicht mehr dazu kommt, Antworten zu geben. Die ursprüngliche Frage lautete aber doch: Marco D. hat folgendes geschrieben: Wieviele Datensätze kann eine MySQL-Tabelle verkraften? Geht der Server deswegen irgendwann in die Knie? Und das hat dann nun mit ner CPU nichts zu tun. Wir hatten bis vor kurzem einen SQL-SErver auf einem 166MHZ-PC mit 4GB Daten am Laufen, der in einer Produktionsumgebung lief. Hier merkte man sehr wohl, welche Abfragen über Indexe liefen, und welche nicht.

Das ist klar, das hat aber mit dem eingesetzen DB-System nichts zu tun, weil JIJO-Prinzip (Junk In --> Junk Out).

alzaimar hat folgendes geschrieben:

Dem Rest deiner Ausführungen entnehme ich, das man MySQL nicht verwenden sollte, die Einschränkungen sind doch einfach zu groß.

Naja, dass MySQL für eine Produktiv-Umgebung relativ gut geeignet ist, sieht man spätestens am DF (und vielen anderen großen Websites). Ich möchte nicht mit Oracle von PHP aus zugreifen ... Allein das OCI-Interface, was PHP einem Vorsetzt, ist grausam; ADO mag mal noch gehen, aber wirklich zufrieden wird man nur mit MySQL bei PHP-Skripts.

alzaimar hat folgendes geschrieben:

Man darf nicht vergessen, das eine gute DB mit wohl durchdacht gesetzen Indexen eine CPU nicht sonderlich belastet (ausgenommen Aggregate), da der Aufwand pro Datensatz O(1) ist. Mit anderen Worten: Das Suchen in einer Tabelle mit 100.000.000 Datensätzen dauert genauso lang, wie in einer Tabelle mit 10 Datensätzen. (Na gut: fast). Dies hat u.A. damit zu tun, das in einer realen Umgebung von den 100.000.000 Datensätzen maximal 1% gerade aktuell, d.h. im Cache gehalten werden.

Auch das leistet MySQL für die gängigen Typen von Abfragen problemlos, wenn man seine Anfragen halbwegs vernünftig formuliert.

alzaimar hat folgendes geschrieben:

Das MySQL so viele Caveats besitzt, ist angesichts der Versionsnummer ein Armutszeugnis und disqualifiziert sie eigentlich für ernstzunehmende Anwendungen.

Juhu, das DF wurde grad disqualifiziert als Ernstzunehmende Anwendung einer MySQL-Datenbank

MySQL ist darauf optimiert, für kurze Anfragen, präzise Antworten zu geben, nicht, aus der Google-Datenbank die Antwort auf die Frage nach dem Universum, dem Sein und allem andren zu liefern, bevor man die Query absetzt Und in dem Bereich ziehe ich MySQL bei weitem einem Oracle-Server vor (ich hab einfach nicht soviele 2GHz-Kisten mit mindestens 8GB RAM rumstehen ...)

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

alzaimar hat folgendes geschrieben:

... Wichtig sind Indexe und ein DB-Design, das sich an der 3.Normalform orientiert.

Von welcher Version redet ihr überhaupt ? 4 oder 5 ? Oder gar 3 ? Frage geht hauptsächlich an Fragesteller. Musste vor kurzem eine DB ins Internet stellen. Das ging nur, nachdem alles wichige aus der DB entfernt wurde (Trigger, SPs usw.). Lässt sich mit mysql überhaupt was vernünftiges machen ? Oder geht es um lokal ?

Moin:
Also? Wie bekommt man MySQL in die Knie?

Antwort:
1. Mit schlechtem DB-Design
2. Mit ohne Indexe
3. Mit Indexen, aber an der falschen Stelle.
4. Mit schlechter Hardware
5. Mit komplexen Abfragen

Und wie bekommt man jede DB in die Knie?
Antwort:
Mit den Punkten 1 bis 4 und z.B. bei MSSQL auch mit 5.

Ergo: Nicht das DBMS ist maßgeblich, sondern der DB-Designer!

Oracle bleibt damit (soweit ich weiss) das Maß aller Dinge. Allerdings auch im Preis und den Hardwarevoraussetzungen.

Trigger und SPs sind ab der 5er IIRC auch bei MySQL dabei; also von daher

@Oracle: Ich hab meine 2 in der DB-Prüfung (wo's um Oracle ging) und das reicht. Das was Oracle kann, kann MySQL im großen und ganzen auch; meist mit weniger Resourcen und oftmals auch wesentlich eleganter

Ich will mir nicht meine Informationen im Katalog anschauen, sondern, dass mir die Datenbank diese zeigt

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.