Datenbank für Große Datenmengen

[Anonym_1a2bbbbf7f29]

Hallo zusammen,

ich nutze zur Zeit einen Linux Webserver mit einer MySql Datenbank hat mir bis jetzt auch gute Dienste geleistet.

nun habe ich ein neues Datenbankprojekt aufgespielt wurde welches aus 11 Tabellen besteht und auf alle Tabellen verteilt ca 60 mio datensätze enthält.

Die meisten felder sind indiziert worden, jedoch habe ich jetzt das Problem das die Datenbankabfragen nun für die Datenbank über 5 Minuten dauern.

hat wer vorschläge / Ideen mit denen ich die Datenbank wieder auf eine halbwegs brauchbare geschwindigkeit bringen kann.

Auf welches Datenbank System könnte ich umsteigen was mit Solchen Größen klarkommt und was am nächsten an der MySql Syntax dran ist.

Wie sieht es mit Oracle aus?

Gruß
Phillip

[M_L_]

Auch hallo.

hat wer vorschläge / Ideen mit denen ich die Datenbank :wieder auf eine halbwegs brauchbare geschwindigkeit :bringen kann.

Ohne jetzt Informationen über die Hardware oder über das Datenmodell zu haben: statt ‚SELECT *…‘ gleich die Zieltabellen ansprechen und Finger weg von ‚DISTINCT‘ (lädt erstmal alles Angesprochene und präsentiert dann nur das Relevante. Was dementsprechend Zeit kostet.)

HTH
mfg M.L.

[Anonym_1a2bbbbf7f29]

Hallo M.L.

Hardware

AMD 64 bit 3 Ghz
2 GB DDR2
80 GB SATA Festplatte

Was für Informationen wären den für dich als Datenmodell Interessant?

---

SELECT * / DISTINCT werden nicht genutzt.

Gruß
Phillip

Auch hallo.

hat wer vorschläge / Ideen mit denen ich die Datenbank wieder auf eine halbwegs brauchbare geschwindigkeit bringen kann.

Ohne jetzt Informationen über die Hardware oder über das
Datenmodell zu haben: statt ‚SELECT *…‘ gleich die
Zieltabellen ansprechen und Finger weg von ‚DISTINCT‘ (lädt
erstmal alles Angesprochene und präsentiert dann nur das
Relevante. Was dementsprechend Zeit kostet.)

HTH
mfg M.L.

[M_L_]

Hallo nochmal.

Hardware

AMD 64 bit 3 Ghz
2 GB DDR2
80 GB SATA Festplatte

Sieht schnell genug aus…

Was für Informationen wären den für dich am atenmodell Interessant?

Das ER-Modell: kann ja sein, dass entweder zuviel oder zuwenig normalisiert wurde. Und für multidimensionale Abfrage sollte man auch Werkzeuge verwenden, die hierfür geeignet(er) sind

---

SELECT * / DISTINCT werden nicht genutzt.

Dann kann man die Abfragen sicher noch weiter präzisieren. In der Zwischenzeit kann man sich im Internet nach dem Schlagwort „SQL-Tuning“ umsehen.

mfg M.L.

[Anonym_1a2bbbbf7f29]

Hallo M.L.

Im endefekt soll das Programm ein Warehouse Tool werden.
Die Daten sind von Sich aus schon von vorneherein schon vor dem Import Normalisiert.

eine beispielabfrage wäre

SELECT `bnr` FROM `isdv` WHERE `letzte_aenderugn` = (SELECT `letzte_aenderugn` FROM `isdv` ORDER BY `letzte_aenderugn` DESC LIMIT 0,1)")

Es sollen über die Datenbank vor allem Statistiken erstellt werden.

Gruß
Phillip

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[Peter_Goppelt_Langer_d5bddf]

Hallo,

die MySQL sollte schnell genug sein (gerade MySQL) und auch für große Datenmengen einsetzbar. Also ein Wechsel der DB erscheint mir nicht nötig.

Was kannst Du also noch tun: Mehr Speicher. Das sollte auf jeden Fall nicht schaden. (Und die MySQL sollte diesen Speicher auch benutzen dürfen. Speicher haben und Speicher benutzen ist ja schließlich nicht dasselbe.

Du kannst natürlich die Daten irgendwie aufräumen. Was sind das für Daten? Historische? Aktuelle? Da lohnt es oft (eigentlich immer) historische und aktuelle Daten zu trennen. (An die Historie muss man meist seltener ran uns ist auch bereit, länger zu warten.)

Indizes auf alle relevanten Abfragen definieren. Das bringt oft am meisten.

Vielleicht hat hier ja jemand ne Ahnung, wie der Optimizer von MySQL funktioniert. Und wie man ihn anstößt. Irgendwo sollte man sich da doch den Ausführungsplan anschauen können.

So wie das nämlich aussieht, kriegt der Optimizer nicht die Kurve, sprich er optimiert falsch. (Nimmt die falschen Tabellen zuerst, benutzt nicht die besten Indizes, optimiert auf die falschen Zeilenanzahlen und Verteilungen)

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[Peter_Goppelt_Langer_d5bddf]

Hallo,

bei deinem Select kann man sicher noch optimieren. Versuch mal:

SELECT `bnr` 
FROM `isdv` 
WHERE `letzte_aenderugn` = (
 SELECT max(`letzte_aenderugn`) 
 FROM `isdv`)

Gruß

peter

Hallo nochmal.

Hardware

AMD 64 bit 3 Ghz
2 GB DDR2
80 GB SATA Festplatte

Sieht schnell genug aus…

Was für Informationen wären den für dich am atenmodell Interessant?

Das ER-Modell: kann ja sein, dass entweder zuviel oder zuwenig
normalisiert wurde. Und für multidimensionale Abfrage sollte
man auch Werkzeuge verwenden, die hierfür geeignet(er) sind

---

SELECT * / DISTINCT werden nicht genutzt.

Dann kann man die Abfragen sicher noch weiter präzisieren. In
der Zwischenzeit kann man sich im Internet nach dem Schlagwort
„SQL-Tuning“ umsehen.

mfg M.L.

Hallo M.L.

Im endefekt soll das Programm ein Warehouse Tool werden.
Die Daten sind von Sich aus schon von vorneherein schon vor
dem Import Normalisiert.

eine beispielabfrage wäre

SELECT bnr FROM isdv WHERE letzte_aenderugn = (SELECT
letzte_aenderugn FROM isdv ORDER BY letzte_aenderugn
DESC LIMIT 0,1)")

Es sollen über die Datenbank vor allem Statistiken erstellt
werden.

Gruß
Phillip

[Anonym_1a2bbbbf7f29]

Hallo

Hallo,

die MySQL sollte schnell genug sein (gerade MySQL) und auch
für große Datenmengen einsetzbar. Also ein Wechsel der DB
erscheint mir nicht nötig.

ok

Was kannst Du also noch tun: Mehr Speicher. Das sollte auf
jeden Fall nicht schaden. (Und die MySQL sollte diesen
Speicher auch benutzen dürfen. Speicher haben und Speicher
benutzen ist ja schließlich nicht dasselbe.

speicher wird genutzt.

Du kannst natürlich die Daten irgendwie aufräumen. Was sind
das für Daten? Historische? Aktuelle? Da lohnt es oft
(eigentlich immer) historische und aktuelle Daten zu trennen.
(An die Historie muss man meist seltener ran uns ist auch
bereit, länger zu warten.)

Aufräumen wäre möglich möchte ich aber eigentlich nicht.
Die Datenbank soll als Basis für ein Statistik Tool dienen welches vor allem dynamische Statistiken zwischen diesem und dem Vorjahr erstellen soll.

Indizes auf alle relevanten Abfragen definieren. Das bringt
oft am meisten.

Indizes sind erstellt.

Vielleicht hat hier ja jemand ne Ahnung, wie der Optimizer von
MySQL funktioniert. Und wie man ihn anstößt. Irgendwo sollte
man sich da doch den Ausführungsplan anschauen können.

So wie das nämlich aussieht, kriegt der Optimizer nicht die
Kurve, sprich er optimiert falsch. (Nimmt die falschen
Tabellen zuerst, benutzt nicht die besten Indizes, optimiert
auf die falschen Zeilenanzahlen und Verteilungen)

Wie könnte ich sowas kontrollieren ? kennt jemand nen gutes tutorial zum MySQL Optimizer ?

Gruß
Phillip

[Anonym_1a2bbbbf7f29]

Hallo,

bei deinem Select kann man sicher noch optimieren. Versuch
mal:

SELECT bnr
FROM isdv
WHERE letzte_aenderugn = (
SELECT max(letzte_aenderugn)
FROM isdv)

Gruß

peter

Werde ich ausprobieren und vergleichen.

Gruß
Phillip

[Hannes_Liesen]

Alle datenbanken werden bei grossen
Datenmengen ganz langsam, was aber relativ
ist.
Wenn man den Nachnamen hat, findet
man eine Telefonnummer sehr schnell,
denn es ist ja danach sortiert,
wenn man nur die Strasse hat, wirds
ziemlich langwierig, die nummern zu finden,
die in Frage kommen.
Auch die dicksten systeme haben da Probleme mit.
Die Lösung sind Indizes oder Indexe.
Das heisst man legt eine alphabetische Liste mit Strassennahmen an
mit den Seiten des Telefonbuchs, auf denen eine Strasse aufgeführt ist.
create index strasseidx on adressen (strasse)
Das führt bei so 100 Mo Adressen zb zu einer Suchzeit
von wenigen sekunden statt Stunden.
select * from Adresse where strasse=‚Bremer Strasse‘
So Datenbanken sind meist aber komplizierter strukturiert als
ein Telefonbuch. Diese Indizierung und die Kontrolle
ob die Indizes greifen, ist eine Kunst für sich.
Und bei ganz ganz grossen Datenbeständen und komplizierten Abfragen
nutzt es auch nicht viel. Je mehr indizes, desto mehr Aufwand
beim schreiben einer Zeile.
Der Stand der Technik zu grossen Datenbankmengen,
die in oft in ihren Gesamtheit abgefragt werden repräsentiert
Teradata, eigentlich. Für den Privatanwender aber zu teuer.
http://www.teradata.com
IBM setzt mit DB2 auf offizielle Benchmarks,
und gewinnt dabei oft in punkto Abfragen auf einzelene Sätze,
in grosse Datenbeständen.
Dass sie die Benchmarks gewinnen, heisst zu erst einmal nur,
dass sie sich bei den Benchmarks besonders viel Mühe gegeben haben.

[Roger_Bieri]

Teradata
Naja, Teradata ist ein massiv-paralles System, speziell für Data Warehousing konzipiert. Da es Daten intern auf verschiedenen Nodes (CPUs & Platten) ablegt, ist es für OLTP-Zugriffe weniger geeignet. Operative Applikationen „picken“ ja meistens nur einen Satz raus um diesen zu bearbeiten.

Aber die Grundaussage stimmt schon: Zum schaufeln riesiger Datenmengen für Analysen gibt’s nichts besseres

[Quaser_76e2b1]

Hi,

Wie könnte ich sowas kontrollieren ? kennt jemand nen gutes
tutorial zum MySQL Optimizer ?

ich nicht

aber mit dem EXPLAIN vor jedem SELECT kannst du dir den Ausführungsplan ansehen.
Der Optimizer von MySQL ist meiner Erfahrung nach eher so lala. Zumindest im 4er. Mit der 5er version habe ich nocht nicht viel gemacht.
Ich war doch ziemlich erstaunt, dass es im Dialekt ein Kommando: „force index“ gibt. Den braucht man auch um den Optimizer zu optimieren.

HTH
Q.

[Peter_Goppelt_Langer_d5bddf]

Hallo,

force index kennen viele Datenbanken (Oracle zum Bespiel).
Mit force Index kann man nicht den Optimizer verbessern, sondern man trickst ihn aus. Der Optimizer ist das bessere Tool, nur manchmal ist er etwas verwirrt.

Es ist unglaublich, was ein einfaches Umstellen der Argumente im WHERE-Block ausrichten kann. Dreist, aber durchaus erfolgreich kann auch das einzelne Indizieren jedes Attributes im WHERE-Block sein. (Ich konnte es kaum glauben, aber es wirkt)

Natürlich kostet das was und zwar gerade bei großen Datenmengen: die INSERTs werden langsamer, weil ja auch die Indexe aktualisiert werden müssen.

Ganz Global kann man aber immer sagen: Finger weg von FORCE INDEX.

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[Quaser_76e2b1]

Hi,

sondern man trickst ihn aus. Der Optimizer ist das bessere
Tool, nur manchmal ist er etwas verwirrt.

Bei MySql ist er aber immer meist verwirrt - insbesondere wenn man nach Datum sortiert/gruppiert.

Es ist unglaublich, was ein einfaches Umstellen der Argumente
im WHERE-Block ausrichten kann. Dreist, aber durchaus
erfolgreich kann auch das einzelne Indizieren jedes Attributes
im WHERE-Block sein. (Ich konnte es kaum glauben, aber es
wirkt)

jupp

Natürlich kostet das was und zwar gerade bei großen
Datenmengen: die INSERTs werden langsamer, weil ja auch die
Indexe aktualisiert werden müssen.

jupp

Ganz Global kann man aber immer sagen: Finger weg von FORCE
INDEX.

nicht bei MySql, Faktor von 10000 war schon drin weil der blöde Optimizer sich geweigert hat einen Index zu benutzen …
Hängt aber wirklich vom Fall ab - nur sollte man alle Werkzeuge kennen und um das ging es hier ja.

Gruss
Q.

[Tomh]

Hi!

Aber die Grundaussage stimmt schon: Zum schaufeln riesiger
Datenmengen für Analysen gibt’s nichts besseres

Ist es nicht so, das Teradata bei sehr niedrigen Datenmengen (so ca. 60Mio. Datensätze noch gar nicht _diesen_ Performance-Gewinn so richtig zeigen kann, sondern sogar noch eine Spur langsamer wirkt(ist?) als z.B. Oracle?

Grüße,
Tomh

[Roger_Bieri]

Naja, objektive Aussagen kann ich dazu jetzt auch nicht machen. Wie gesagt, der verteilt die Sätze ja auf seine Nodes. Mit geschickter Wahl von Schlüssel und Indexen (Partition Indexes) kannst du dafür sorgen, dass kleine Tabellen vollständig auf einem Node abgelegt werden und bei riesen Tabellen z. B. alle Sätze eines Jahres auf einem Node liegen. Dann hast du den gleichen effekt, wie bei einer „normalen“ DB.