nicht angemeldet
MySQL und Anzahl von Datensätzen
Hallo!
Ich würde mal gerne wissen wie Eure Erfahrung mit MySQL und großen Anzahlen von Datensätzen ist. Ich möchte Attribute einer Matrix innerhalb der Datenbank verwalten, und es wird für jede Koordinate ein Datensatz angelegt. Dadurch entstehen in der DB bis zu eine Menge Datensetze.
Wie viele Datensätze kann man mit MySQL in venünftiger Zeit verwalten.
-
Nach dem was ich gelesen habe, wofür MySQL alles eingesetz wird, ist dem eigentlich keine Grenze gesetzt.
Der erste Flaschenhals wird wahrscheinlich die Übertragung der Datenbankinhalte ins Internet sein.
Der zweite Flaschenhals wird dann die Arbeitsspeichergröße sein, durch die die Abarbeitung so großer Datenmenge verlangsamt wird.
Danach wird es dann an der Prozessorgeschwindigkeit liegen.
Schließlich wirst du Probleme mit der Festplattenkapazität haben.
Und Schlussendlich, wenn du also eine 1GB-Internt-Anbindung, 1GBArbeitsspeicher und ein 100GHz-Prozessor hast, Festplattenplatz von einigen Terrabyte, dann wirst du wahrscheinlich langsam an die Kapazitätsgrenze von Mysql kommen, dass dann innerhalb des Programms Mätzchen auftreten.
Solltest du phpMyAdmin in etwas älterer Version benutzen, das macht schon ziemlich schnell Mätzchen...
-
Tjaa....
ich hatte so an die 9000+1000+20000=30000 *juhuu* Datensätze gedacht, die sich dann auf verschiedene Tables verteilen. Bis jetzt habe Ich noch nie mit so großen Datenbanken gearbeitet und weiß auch nicht, was diese denn an Rechenpower sowie Anbindung brauchen.Danke.
sui-
mit solchen MiniDB's kommt man ja sogar fast schon mit Access durch *ggg*
-
Hi sui,
ich hatte so an die 9000+1000+20000=30000 *juhuu* Datensätze gedacht,
große Tabellen sind kein Problem.
Schlecht optimierte Zugriffe (fehlende Indexstrukturen etc.) schon eher.Deine 20000er-Tabelle linear zu lesen ist eine Kleinigkeit.
Aber sie mit der 9000er-Tabelle zu JOINen, kann bei hinreichend ungeschickter Wahl der Tabellenattribute das Produkt der beiden Zeilenzahlen an Ergebnissen produzieren - da werden die Zahlen dann ziemlich schnell ziemlich groß.Viele Grüße
Michael
(der mit mySQL eine Suchmaschine betreibt, deren Kern-Tabelle 15 Millionen Datensätze enthält und jeden Morgen in ca. 30 Minuten komplett neu importiert und geindext wird)-
Hi!
große Tabellen sind kein Problem.
Schlecht optimierte Zugriffe (fehlende Indexstrukturen etc.) schon eher.Deine 20000er-Tabelle linear zu lesen ist eine Kleinigkeit.
Aber sie mit der 9000er-Tabelle zu JOINen, kann bei hinreichend ungeschickter Wahl der Tabellenattribute das Produkt der beiden Zeilenzahlen an Ergebnissen produzieren - da werden die Zahlen dann ziemlich schnell ziemlich groß.Ja, das hatt ich auch schonmal gehört, da wohl tremporäre "tabellen" dann mit 20000*9000 DS erstellt werden.. oder wie war das? Ist es dann auf der anderen Seite besser eine Abfrage zu machen und dann in einer Schleife noch mehr Abfragen?
(der mit mySQL eine Suchmaschine betreibt, deren Kern-Tabelle 15 Millionen Datensätze enthält und jeden Morgen in ca. 30 Minuten komplett neu importiert und geindext wird)
Was denn für eine Suchmaschine? Woher kommen die Daten? Warum importierst Du immer alle und aktualisiertst nicht lediglich die geänderten? Was ist an "indexen" so ein Problem?
Womit machst Du das alles? Wahrscheinlich mit PERL, richtig? Bei PHP kann mir ehrlich gesagt nicht vorstellen, dass ein Script 30 Minuten läuft, auf gehosteten Servern wird sowas eh gekillt. Ist es wohl ein Problem mit PHP solche Daten zu verwalten?
Viele Grüße
Andreas-
Hi Andreas,
Ja, das hatt ich auch schonmal gehört, da wohl temporäre
"tabellen" dann mit 20000*9000 DS erstellt werden.. oder
wie war das?Bei
SELECT A.X, B.Y
FROM A, B
WHERE A.Z = B.Z
AND A.M = '57'
AND B.N = '42'wird die Datenbank sinnvollerweise _zuerst_ die Teilmengen der 57er und 42er-Datensätze bilden und nur für diese das kartesische Produkt ausmultiplizieren. Das ist meistens um Größenordnungen effizienter als anders herum, falls die Spalten M bzw. N hinreichend stark projezieren.
Sollte das nicht der Fall sein, also am Ende wirklich Millionen von Treffern heraus kommen, dann hat der Benutzer das so gewollt.Ist es dann auf der anderen Seite besser eine Abfrage zu machen
und dann in einer Schleife noch mehr Abfragen?Je besser die Datenbank, desto überzeugter würde ich sagen: "Nein, eher das Gegenteil."
Eine gute Datenbank kann die Inhalte von M und N beispielsweise analysieren (SQL-statement 'ANALYZE TABLE') und die Information, ob diese Spalten stark projezierend sind oder nicht, separat speichern - und basierend auf diesem Wissen dann entscheiden, in welcher Reihenfolge sie die Operationen in ihren Ausführungsplan aufnimmt.Die Entscheidung, statt einer mächtigen SQL-Query lieber eine entsprechende Verarbeitungslogik in 3GL zu bauen, ist für mich vergleichbar mit der Entscheidung, in Assembler zu programmieren statt in einer Hochsprache, weil Du dem Compiler nicht traust.
Was denn für eine Suchmaschine?
Eine Suchfunktion eines Intranet/Extranet-Produkts unserer Firma.
Woher kommen die Daten?
Von der Maschine nebenan (die keinen HTTP-Anschluß hat, sondern nur proprietäre APIs, und auch keinen Webserver haben darf, weil sie unter hoher Last Realtime-Daten annehmen muß; meine Suchmaschine wird nur mit einem snapshot von Adressierungssystemen der eigentlichen Daten geladen, die sich intraday nicht mehr ändern - die Nutzdaten ändern sich ggf. sekündlich).
Warum importierst Du immer alle und aktualisiertst nicht lediglich
die geänderten?Weil ich dafür herausfinden müßte, was sich geändert hat, und zudem INSERT und DELETE ausführen. Und dafür dann eventuell einige hunderttausend oder gar millionen mal ein halbes Dutzend Indexbäume pro INSERT und DELETE lokal anpassen - das ist ganz schön langsam, kann ich Dir sagen.
Außerdem - eine Datenbank mit vielen Änderungen degeneriert im Laufe der Zeit ihre Indexbäume, die müßte ich dann irgendwie reorganisieren.
Das alles spare ich mir.Was ist an "indexen" so ein Problem?
Daß sie bei Schreiboperationen mit gepflegt werden müssen - und zwar einsortierend.
Stell Dir eine Tabelle mit 10 Spalten vor, wobei auf jeder Spalte ein separater Index liegt (im Wesentlichen eine Übersetzungstabelle zwischen "Sprachen). Jetzt fügst Du einen Datensatz ein. Das ist eine Schreiboperation auf die Tabellendaten - kein Problem - und danach 10 sortierende Einfügeoperationen auf jeden der Indexbäume, also jeweils mit logarithmischem Aufwand die Einfügestelle suchen! Mach das mal mit einer Tabelle mit 15 Millionen Datensätze (log2 (15Mio) ~ 24), dann hast Du eine Schreiboperation, aber 240 Index-Lesezugriffe für jeden Datensatz! Ach ja, die 10 Schreibzugriffe für die Indexeinträge kommen auch noch dazu, ich vergaß.
(Ich habe übrigens noch einen weiteren Faktor von 20 unter den Tisch fallen lassen, der hier aber zu weit in die Logik der Anwendung führen würde.)
Die inkrementelle Methode würde mich umbringen, wenn sich plötzlich ein paar Millionen Zeilen ändern (wogegen ich gar nichts tun könnte).Womit machst Du das alles? Wahrscheinlich mit PERL, richtig?
Ja.
Bei PHP kann mir ehrlich gesagt nicht vorstellen, dass ein Script
30 Minuten läuft, auf gehosteten Servern wird sowas eh gekillt.Wer hat etwas von CGI gesagt?
Außerdem ist das natürlich in gewisser Weise meine eigene Maschine. (Genauer gesagt die Maschine der Webhosting-Anwendung, in welche ich die Suchmaschine eingebaut habe.)Ist es wohl ein Problem mit PHP solche Daten zu verwalten?
Keine Ahnung - ich kann kein PHP, vor allem kein nicht-HTTP-PHP.
Aber den Datenbank-Lader würde ich bestimmt nicht über eine HTTP-Schnittstelle starten - der läuft los, sobald auf dem Nachbar-Rechner frische Adressierungsdaten angekommen sind (der wiederum wird über eine Satellitenschüssel online beliefert ...).
Viele Grüße
Michael
-
-
-
-
-
Hi,
Wie viele Datensätze kann man mit MySQL in venünftiger Zeit verwalten.
MySQL ist an sich eine recht schnelle Datenbank, also sollte es daran nicht scheitern. Wie Julian schon sagt, ist das nicht das schwächste Glied der Kette. Da gibts andere Punkte...
Jan
-
Hi,
Wie viele Datensätze kann man mit MySQL in venünftiger Zeit verwalten.
es ist zwar schon gesagt worden, dass Deine 30000 Datensätze für MySQL ein ziemlicher Pups sind (ein halbwegs gescheiter Rechner vorausgesetzt), aber ich wollte trotzdem noch meinen Senf dazu geben.
Ich habe mal einen Prototypen eines Prozessdatenvisualisierungssystems geschrieben, der Messdaten von grossen Industrieanlagen im Browser visualisieren kann (im Intra- wie auch im Internet). Jeder Standort (also eine Frabrik o.ä.) bekam seine eigene MySQL-Datenbank, in der die Messdaten gespeichert wurden. An einem Standort (in Simulation) kam es vor, dass bis zu 20 separate Messkanäle (Temparatur-, Geschwindigkeits- und andere Messgeräte) Werte in die Datenbank schrieben. Und zwar mit Samplingraten von bis zu einer 1/100tel Sekunde.
Für den Prototypen haben wir eine Anwendung mit
8 Kanälen, 1 32bit-Wert / Sekunde (1Hz)
4 Kanälen, 10 32bit-Werte / Sekunde (10Hz)
1 Kanal, 100 32bit-Werte / Sekunde (100Hz)
simuliert.Das macht summa summarum pro Stunde:
60*60*8 = 28800 DS
60*60*4*10 = 144000 DS
60*60*1*100 = 360000 DS
also 532800 DS pro Stunde. Nettodatenmenge ca. 2MB, mit Kanal- und anderen Infos ca. 3MB. (Weis nicht mehr genau, wieviel Plattenplatz die Tabellen- und Indexdateien gebraucht haben...).Die Anwendung lief auf einem 1Ghz, PIII mit 512MB RAM unter Red Hat Linux 7.0. Zusätzlich lief auf dem Rechner ein Apache-Webserver mit den Perl-Skripten für die Visualisierung der Daten. Um die zu übertragenden Daten möglichst kompakt zu halten, wurden die Visualisierungsgrafiken (Kurven, Diagramme...) anhand der Usereingaben auf dem Server berechnet und als .png-Grafik zum Browser geschickt.
Vielleicht ist dazu zu sagen, dass MySQL nur sehr einfache Queries bearbeiten musste und nur in den wenigsten Fällen kleine Teilmengen dieser Daten irgendwie zu sortieren oder zu sonstwasen hatte. Ausserdem wurde diese Menge an Datensätzen nicht ganz in Echtzeit in die Datenbank geschrieben, sondern von der Anwendung, die die Daten erfasst "mundgerecht" verabreicht.
Aus diesem Prototypen ergab sich zwar, dass das Projekt in dieser Form nicht realisierbar war, aber MySQL hat die Simulation locker überstanden. Insgesamt haben wir ca. drei-vier Stunden aufgezeichnet.
Viele Grüsse
Achim Schrepfer