Hallo!
Ich habe mal ein paar theoretische Fragen zur MySQL-Performance:

Wie groß wäre eine Tabelle mit 117.649.000.000 (567.869.252.000) Einträgen? Wäre soetwas realisierbar? rein technisch. Welche Rechnerperformance bräuchte man?

Wie lange würde ein SELECT-Befehlt mit einem Element in der Ergebnismenge bei einer Tabelle mit 117.649.000.000 (567.869.252.000) Einträgen dauern?

Ich muss mich für die Absurdität dieser Frage entschuldigen..

Danke schonmal für eure Antworten

Mister Ad

Zergling-new

Eine Tabelle mit 117 Milliarden Einträgen? Darf man fragen wozu?
Kann deine theoretischen Fragen nicht beantworten, aber im Einsatz/in der Praxis kann du soetwas gleich vergessen, dafür ist MySQL nicht konzipiert.

ninguno

ja da ist wohl eher Oracle oder DB2 gefragt

mepeisen

Investiere mal etwa 1.000.000 Euro und stell dir eine entsprechende IBM Blackbox hin, auf der DB/2 läuft.
In umserem RZ läuft bei diesem ungefähren Umfang (es sind logischerweise nicht nur eine Tabelle, sondern mehrere aufgrund Ausfallsicherheit, aber egal.) ein DB/2 auf OS/390. Altbacken nennen es einige, aber es läuft bei 99,9% Verfügbarkeit...

Fazit: Wenn du in diesen Dimensionen denkst, dann musst du auch finanziell und entsprechend Hardwaretechnisch in deutlich anderen Dimensionen denken, egal ob du Oracle oder DB/2 nimmst.

P.S.: Auch MySQL kann inzwischen auf diesen Dimensionen arbeiten. Es hat einige andere Nachteile gegenüber DB/2 oder Oracle, die aber nicht direkt etwas mit Massenabfertigung zu tun haben. Performance-Vergleiche sind bei diesen Dimensionen nicht machbar, da jedes der Systeme eigene Regeln für Optimierungen hat und man daher nicht eins zu eins Performance vergleichen kann...

Zergling-new

Kannst du das mal ausführen?

mepeisen

Es gab bei uns jüngst Untersuchungen bezüglich neuer Datenbanksysteme und dabei wurde ebenfalls MySQL untersucht. Umfang sind bei uns etwa 200 Mio Datenbank-Transaktionen pro Tag, wenn ich die Intranet-News richtig im Kopf habe. 117 Milliarden Tabelleneinträge erreichen wir glaube ich nicht, aber die 10 Milliarden in einigen Tabellen durchaus.

Jedenfalls kam dort einhellig heraus, dass alle drei hier genannten Systeme bei Massenabfertigung durchaus realistische Antwortzeiten liefern können. Dabei wurden logischerweise entsprechende Cluster-Lösungen untersucht. Sicherlich gab es deutliche Unterschiede bei der Architektur, weswegen das ebenbürtig in Anführungszeichen steht. Oracle und MySQL sind um einiges günstiger im IT-Betrieb, unter anderem, weil sich IBM die großen schwarzen Kisten sehr gut bezahlen lässt.

Es gibt nach wie vor starke Unterschiede im Funktionsumfang und beispielsweise bei Support/Gewährleistung. Da ist die IBM einfach ein anderes Kaliber. Ansonsten war ein Hauptgrund, dass diverse Funktionen, wie Views und Subqueries bei MySQL noch relativ jung sind und daher ein deutlich größeres Risiko besteht. Daher fiel es relativ früh durch das Sieb.

Alleine weil unsere Architektur-Truppe durchaus betonte, dass die Systeme in den Untersuchungen ebenbürtig waren, gehe ich davon aus, dass MySQL nach wie vor gewaltig unterschätzt wird. Erfahrungen fehlen mir leider konkret bei diesen Dimensionen und entsprechende Hardware zum mal ebend ausprobieren habe ich leider auch nicht

Wie gesagt hat MySQL in anderen gebieten Nachteile, die man nicht so ohne weiteres aufholen kann und die gerade bei diesen großen Dimensionen einrfach wichtiger sind...

Interessantes Thema.

Anderseitsk, kann man solche Datenmengen überhaupt seriös bzw. legal erheben ?
Selbst Amazon und Ebay zusammen dürften soviel nicht zusammenbekommen.
Allenfalls große Telekommunikations-Provider die jeden Müll für selbstbeschäftigungssuchende Behörden mitloggen müssen.

Teilchenbeschleuniger wäre noch ein Fall.....


100 Mio. DB-Transaktionen pro Tag entspricht der Volllast von mindestens 14 gut ausgestatten klasschischen LAMPs

Mit guten Willen bekommt ein klassischer und hardwaremäßig gesteuert LAMP (Linux,Apache, MySQL) 2000 Datensätze pro Sekunde reingezogen.

Eine solche Architektur verbietet sich dann allerdings für die Aufgabe. Da muß dann etwas mehr aufgetragen werden. Alleine schon aufgrund der Datenmenge. Die normalen Systeme haben eine Filegröße von max. 2 GB . Muß also mind. ein 64-bittiges System bzw Filesystem oder besser noch RAW-Device her. Also auch eher abseits der PC-Architekturen, eher was von IBM, Sun oder HP.

Zu trennen ist bei Mysql auch der EInsatz von MyISAM-Tabellen und den InnoDBs. Bei ersteren ist Datentabelle und Index getrennt in jeweils einem File. Von der Geschwindigkeit her tun die beiden sich bei "normalen" Abfragen nicht viel.

MyISAM verbietet sich eigentlich bei so großen Menge deswegen weil die komplette Tabelle für andere Schreiber und zum Teil auch Leser gesperrt wird. Bei vielen parallelen Zugriffen ein echter Flaschenhals. Dann lieber row-level-locking wie InnoDB.

Die Zugriffsgeschwindigkeit auf einzelne durch Index versehene Daten ist bei einem halbwegs ausbalancieren Index kaum zu überreffen. Die verwendeten B*- Bäume sind rattenschnell. Maximal 36 Baumebenen erforderlich um einen gezielten Datensatz zu bergen.
(für 117.000.000.000 datensätze)

Einfach mal hochrechnen wieviel Speicherkapazität erforderlich ist.
Da dürften schon einige Dutzend oder hundert Bytes pro Datensatz zusammenkommen. Paßt natürlich auch nur in ein SAN.


Bei solchen Projekten hat auch der Hersteller mit im Boot zu sitzen. Die "Gewährleistung" muß natürlich auch bezahlt werden.

mepeisen

Sicherlich, aber ich spreche hier nicht von einer Web-Anwendung, zumindest nicht im eigentlichen Sinne (Es gibt ein Web-Interface, aber das ist eher unerheblich).

Blackboxen

Zergling-new

Ja.

Wir hatten bei größeren Projekten bisher die Erfahrung gemacht, dass gerade bei Gewinnspielen die im TV beworben werden sekündlich dutzende Eintrage in die DB kommen. Die Eintrags-Dauer wurde für den Besucher inakzeptabel. Das schon bei mehreren hunderttausend Einträgen bereits.
Deshalb überrascht mich, dass MySQL mit hundert Millionen Einträgen so fix umgehen kann (eurer Behauptung nach). Das setzt ja wohl aber eine kostenspielige Hardware-Optimierung voraus.

Bin nicht umsonst nicht MySQL Mod - daher die Frage:
Wie optimiere ich denn MySQL-Tabellen für INSERTs oder UPDATEs?
Reicht es schon, wenn ich für eine Tabelle in die praktisch nur eingetragen wird, auf den Primärschlüssel/Indexe zu verzichten?


Ich befürchte ja, hier sind aber vom Threadstarter nur Phantasien am Laufen (zB alle möglichen md5-Keys zu speichern o.ä.)

mepeisen

Ich meine oben irgendwas von Clustern geschrieben zu haben. Sicherlich sind da einzelne Maschinen überfordert und MySQL für die schwarzen Schränke gibt es glaub ich nicht aber man darf auch nicht unterschätzen, was DB/2 an Hardware-Bedarf bei diesen Dimensionen braucht...
Unsere Blackboxen für die Datenbanken kriegt man nicht so ebend mit einer einzelnen 4-Prozessor-Maschine und vielleicht 2 Gig RAM ersetzt...

Der Primärschlüssel macht nicht direkt einen großen Overhead aus, auch wenn es spürbar schneller werden kann. Das erste ist das Verwenden alternativer Locking-Mechanismen. DB/2 bietet intelligentere Paging und Locking Mechanismen von Haus aus an, aber die muss man auch geschickt nutzen bzw. die Tabelspaces entsprechend vorher geschickt einrichten, sonst wirds gar langsamer wie MySQL. MySQL bietet wie bereits oben stand mit MyISAM per Standard ein für große Datenmengen relativ ungeschicktes Speicher-System an. Das bedeutet aber nicht, dass es nicht inzwischen auch anders könnte.

Generell meine ich oben geschrieben zu haben, dass man natürlich entsprechende Performance-Bremser berücksichtigen muss und im Vorfeld schauen muss, ob man die in den Griff kriegt bzw. nie einfach was daneben stellen darf ohne Grundkenntnisse. Es gibt durchaus genug Anwendungsbeispiele mit deutlich weniger Datensätzen, wo DB/2 ohne gewisse Grundregeln penetrant Indices-Nutzung verweigert und damit Ergebnisse eines Selects etwa in der tausendfachen Zeit holt, als es MySQL tut. War alles schonmal da gewesen.
Und Leutchens wie ich, die aus dem Test ein "Alles arschlangsam" kriegen und dann nicht zuerst "RUNSTATS" im DB/2 laufen lassen, können ein Lied davon singen, dass sie versuchen, was zu beschleunigen, was eigentlich schnell ist *g*