Wie viel Daten verträgt eine MySQL DB?
Stefan Hilfiker
Für wie viele Einträge ist MySQL noch geeignet?
Hat man noch eine angemessene Performance mit dieser DB:
rund 100 Millionen Einträge a 150-200 Zeichen in 3 Spalten.
Rund 200 Connection auf einmal, die darin was suchen (zum grossteil nur read
anfragen).
Was habt ihr so für Erfahrungen? Wann ist eine DB zu gross für MySQL?
Gruss
Stefan
Jens Gesing
also für mich klingt die Größe ein wenig komisch. Aber egal. Ich hab mal ein
Programm gehabt, das bei 70 Connections via mysql_connect (also keine reinen
Zugriffe, sondern die danach noch zusätzlich) mit der C++ API unter Windows,
den MySQL Server auf meinem Rechner überlastet hatte.
Ich gehe mal davon aus, daß die Performance doch sehr stark vom verwendeten
Datenbankrechner und dessen Auslastung abhängt.
MfG
Jens
P.S.: Ich hab dann natürlich in meinem Proggi damals in einer späteren
Version nicht mehr immer mit mysql_connect für jede Abfrage eine Verbindung
aufgebaut. Das war damals nur in der ersten Version so. Fragt bitte nicht,
wie ich darauf gekommen bin :)
--
-------------------------------
Jens Gesing
Webmaster C++ Central
URL: http://www.cppcentral.de
Email: webm...@cppcentral.de
-------------------------------
"Stefan Hilfiker" <xo...@yahoo.de> schrieb im Newsbeitrag
news:b8mjgd$f9t$1...@rex.ip-plus.net...
Harald Stowasser
> Was habt ihr so für Erfahrungen? Wann ist eine DB zu gross für MySQL?
lesen:
http://www.dclp-faq.de/q/q-mysql-eignung.html
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--- s+:+ a C++++ UL+++ P--- L+++ E+ W+++ N++ o+++ K- w+++
O-- M-- V-- PS++ PE-- Y+ PGP++ t++ 5 X- R+++ tv- b+++ DI+++ D+++
G e++ h r++ y+++
------END GEEK CODE BLOCK------
Axel Schwenke
> Für wie viele Einträge ist MySQL noch geeignet?
>
> rund 100 Millionen Einträge a 150-200 Zeichen in 3 Spalten.
Also ca. 20 Gigabyte. Wenn das alles in eine Tabelle soll, müssen
Betriebssystem/Filesystem mit so großen Files zurecht kommen.
> Rund 200 Connection auf einmal, die darin was suchen (zum grossteil nur read
> anfragen).
Was ist "suchen"? SQL-Datenbanken sind effizient für Suche nach
strukturierter Information. Wenn du Volltextsuche meinst: dafür ist
MySQL eher schlecht geeignet.
> Hat man noch eine angemessene Performance mit dieser DB:
Das kommt auf die Hardware und deine Definiton von "angemessen" an.
> Was habt ihr so für Erfahrungen? Wann ist eine DB zu gross für MySQL?
Ein oft unterschätztes Problem sind Backup und (Crash-)Recovery.
Meine Erfahrungen mit MyISAM-Tabellen sind eher ernüchternd. Ein Backup
LOCKt mindestens eine Tabelle für seine Laufzeit. Um 20 GB in angemes-
sener Zeit[1] wegzuschreiben, braucht man schon sehr dicke Hardware[2].
Oder man geht Umwege[3]. Nach einem Crash ist es Unsinn, eine 20GB-
Tabelle reparieren zu wollen. Bleibt also nur das Einspielen des
letzten Backups und Nachfahren der Updatelogs. Auf jeden Fall ist die
Downtime deutlich spürbar.
Mit InnoDB-Tabellen sollte alles deutlich entspannter zugehen.
Allerdings habe ich da (noch) keine nennenswerten Erfahrungen.
[1] Das hängt natürlich von der Applikation ab. Wenn man täglich ein
mehrstündiges Wartungsfenster hat, ist das kein Problem mehr.
[2] Aktuelle Platten schaffen etwa 20MB/s. Für 20GB brauchen wir also
rund 1000s ~ 17min. Backup über 100MBit-LAN doppelt so lange.
[3] Man könnte z.B. ein Replikat aufsetzen und das Backup davon ziehen.
Oder man investiert in eine Storage-Lösung mit Snapshot-Möglichkeit.
XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau
W.Riechmann
Wir haben ne Konfiguration die schiesst 1200MB/S aufs Band.
>
> [3] Man könnte z.B. ein Replikat aufsetzen und das Backup davon
> ziehen. Oder man investiert in eine Storage-Lösung mit
> Snapshot-Möglichkeit.
su
willi
Guido Stepken
Z.B. wenn man 39 Mio Datensätze aus der Klicktel exportiert als ASCII
(CSV) vorliegen hat, ist MySQL etwas überfordert. Der Import von etwa 1
GByte CSV in eine Tabelle mit gesetztem INDEX dauerte 17 Stunden, weil
nach Import jedes einzelnen Datensatzes MySQL den INDEX neu berechnete.
Also mußte ich den INDEX nach dem Import setzen, da war er nach wenigen
Minuten fertig. Fulltext Index, der auch Substrings findet, dauert
jedoch sehr viel länger, mehrere Stunden.
Der Import aller 39 Mio Datensätze scheiterte, MySQL brach ab. Erst das
Aufteilen in 10 Portionen mit dem UNIX SPLIT Kommando half weiter.
Die Suchzeiten von MySQL in der Datenbank sind recht gut, jedoch bei
mehr als 5-6 Clients bricht MySQL zusammen, und der RAM - Verbrauch
steigt stark an. Die neuen Features mit dem Caching der Resultsets von
Queries beschleunigen zwar die Datenbank, jedoch der RAM - Verbrauch und
Plattenverbrauch steigt enorm an.
Ich testete MySQL 3.22.x, 3.23.x, 4.0.x, 4.1beta...überall dasselbe.
Ähnliches hat mir auch jemand berichtet, der nun die Datenbank Cache von
Intersystems einsetzt.
PostgreSQL zeigt in der neuen Version diese Schwierigkeiten nicht.
Gru/3, Guido Stepken
Marcus Fihlon
Guido Stepken <ste...@little-idiot.de> schrieb:
>Z.B. wenn man 39 Mio Datensätze aus der Klicktel exportiert als ASCII
>(CSV) vorliegen hat, ist MySQL etwas überfordert. Der Import von etwa 1
>GByte CSV in eine Tabelle mit gesetztem INDEX dauerte 17 Stunden
Du solltest das lieber einschränken - Deine Hardware/OS-Kombination war
überlastet. Die Geschwindigkeit solcher Operationen ist sehr stark von
der verwendeten Hardware abhängig. Ich im- und exportiere öfter große
Datenmengen im Bereich mehrerer GB. Gestern abend lief der Import von
ca. 18 GB in etwa einer Viertelstunde durch (so ein System möchte ich
auch gerne privat haben ;-)). Sowohl beim Im- und Export als auch beim
Indizieren ist ganz besonders der Datendurchsatz des Speichersystems
gefragt. Eine optimal angepasste Lösung aus Hardware-RAID mit schnellen
SCSI-Platten und entsprechendem Cache-Speicher auf dem Controller
sollten bei "professionellen" (produktions- und
geschwindigkeitsrelevanten) Lösungen schon gegeben sein.
$0.02
Marcus :-)
--
ICQ: 5958110
PGP-Key: 0xD5079840
Registered Linux User: 53312
Homepage: http://www.fihlon.de/
Guido Stepken
also doch entpackt erheblich mehr ....
Hardware: P 1000 mit 8 MByte/Sekunde Notebookplatte.
Matthias Esken
> Sorry, ich vergaß zu erwähnen, daß die 1 Byte BZIP2 komprimiert waren,
> also doch entpackt erheblich mehr ....
Hmmm, welche Daten kann man denn mit bzip2 auf 1 Byte packen?
SCNR,
Matthias
--
Einige nennen Dich Vollquottel? Andere nennen Dich TOFU-Poster?
Man mag Deinen Zitierstil nicht!
Dem kann abgeholfen werden: http://got.to/quote
Guido Stepken
Stefan Hilfiker
"Guido Stepken" <ste...@little-idiot.de> schrieb im Newsbeitrag
news:b8rfs0$9qg$01$1...@news.t-online.com...
Matthias Esken
> Guido Stepken <ste...@little-idiot.de> writes:
>
>> Hardware: P 1000 mit 8 MByte/Sekunde Notebookplatte.
>
> Yep. Versuch dasselbe mit einer E280 und zwei T3 als RAID0+1
> hinten dran und es tut nicht mehr weh.
Die Sun 15K, die demnächst eintrudelt, sollte das auch recht flott
hinbekommen.
Gruß,
Matthias
Marcus Fihlon
>PS: E10K gibt es sehr günstig bei eBay. Zwei Kollegen von mir haben sich
> gerade Privat so eine geschossen. Ich glaube, wir sind bald der Laden
>mit der größten geschlossenen E10K-Zertifizierungsquote in Deutschland. :-)
Ich frage mich immer, wo die Leute sowas hinstellen - ins Wohnzimmer?
Naja, vielleicht - ich habe mal das Gehäuse einer E10K gesehen, die zu
einer "Bierzapfmaschine" umgebaut wurde.
Ich baue zwar meinen Dachboden zum Arbeitszimnmer aus und hätte da auch
flächenmäßig gesehen genug Platz - aber wie kriege ich das Ding da hoch?
Dach aufreißen? ;-)))
cu
Marcus
Stephan Zimmermann
> Hat man noch eine angemessene Performance mit dieser DB:
>
> rund 100 Millionen Einträge a 150-200 Zeichen in 3 Spalten.
> Rund 200 Connection auf einmal, die darin was suchen (zum
> grossteil nur read anfragen).
Das hängt extrem von deinen Anfragen ab. Du bekommst auch auf Tabellen
mit ein paar zehntausend Sätzen Anfragen hin, die Stunden dauern ;-)
Sekundär natürlich auch von deiner Hardware.
Grüße, Stephan
Timo Maier
>Das hängt extrem von deinen Anfragen ab. Du bekommst auch auf Tabellen
>mit ein paar zehntausend Sätzen Anfragen hin, die Stunden dauern ;-)
Mit der Datenbank auf Floppy kein Thema.
--
http://tam.belchenstuermer.de/
Ich grüße meine Mama, meinen Papa und ganz besonders meine Eltern.