Hallo nochmal!
Habe ein neues Problem bezüglich Abfrage Geschwindigkeit.
Und zwar brauche ich derzeit eine Abfrage die über zwei Tabellen geht.
habe es einmal mit einem INNER JOIN und einmal mit einem normalen SELECT (WHERE a.x = b.x) probiert.
Bei größeren Daten dauert die Abfrage aber unglaublich lange.....bei kleineren Abfragen funktioniert es deutlich schneller.
Habe Indizes gesetzt.
Verwende sqlite. Irgendwer eine Lösungsidee?
mfg
Philipp
Sehr große Datenbank
- Käptn Haddock
- User
- Beiträge: 169
- Registriert: Freitag 24. März 2006, 14:27
Wieviel RAM steht dir denn zur Verfügung? Richtig schnell kann das erst werden, wenn genug Platz im Speicher ist um dort Daten zwischen zu speichen. Und es kommt natürlich drauf an, wie groß deine Ergebnismenge ist.
Für große Datenmengen würde ich im übrigen was anderes als Sqlite nehmen. Bei Postgres kannst du z.B. Logging, Indices und Daten auf unterschiedliche Spindeln legen, was das ganze etwas beschleunigt.
Gruß Uwe
Für große Datenmengen würde ich im übrigen was anderes als Sqlite nehmen. Bei Postgres kannst du z.B. Logging, Indices und Daten auf unterschiedliche Spindeln legen, was das ganze etwas beschleunigt.
Gruß Uwe
---------------------------------
have a lot of fun!
have a lot of fun!
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo Philipp!Killver hat geschrieben:Bei größeren Daten dauert die Abfrage aber unglaublich lange.
Diese Probleme hast du auch bei ausgewachsenen Datenbanksystemen. Ich hatte schon Abfragen am Laufen, die über sechs Stunden (oder war es noch länger?) arbeiteten. Das Hauptproblem war die große Anzahl an Datensätzen in einer Tabelle.
Solche Monsterabfragen kann man entschärfen, indem man temporäre Tabellen mit nur mehr den unbedingt benötigten Daten erstellt. Nehmen wir mal an, du hast eine große Tabelle mit Personen und deren Geburtstagen. Wenn du nur die Daten der zweiten Tabelle benötigst, bei denen in der ersten Tabelle die Personen in den letzten 10 Jahren geboren wurden, dann kannst du dir eine temporäre Tabelle mit den *gefilterten* IDs der Personen und deren Geburtstage erstellen. Nachdem du dort alle benötigten Daten abgelegt hast, kannst du diese Tabelle indizieren.
Diese temporäre Tabelle als einer der beiden Partner in einer JOIN bringt dich schon mal sehr viel schneller ans Ziel. Vielleicht kannst du auch die zweite Tabelle abgespeckt in eine temporäre Tabelle bringen. Je nach komplexität der Abfrage bringt dir das sicher auch wieder was.
Mit Hilfe von temporären Tabellen konnte ich solche Monsterabfragen weit über den Faktor 10 schneller machen. Ob es noch schneller war, das weiß ich nicht mehr -- ist einfach schon zu lange her.
Das Datenbankmanagementsystem weiß halt nicht immer selbst den besten Weg um ans Ziel zu kommen.
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Die Idee hatte ich auch schon aber das wird sich nicht lösen lassen.
Ich habe in der ersten Tabelle gewisser IDs und ind er zweiten riesigen Tabelle ebenfalls ids und zugehörige Daten und ich muss dann eben ein join auf die IDs machen, jedoch kann ich dasd nicht händisch amchen....
Edith: nochne Anmerkung...ein Count(*) auf meine Abfrage geht relativ schnell.
Aber ich brauch ebenfalls ein GROUP BY und vorne ein COUNT(DISTINCT spalte)
Ich habe in der ersten Tabelle gewisser IDs und ind er zweiten riesigen Tabelle ebenfalls ids und zugehörige Daten und ich muss dann eben ein join auf die IDs machen, jedoch kann ich dasd nicht händisch amchen....
Edith: nochne Anmerkung...ein Count(*) auf meine Abfrage geht relativ schnell.
Aber ich brauch ebenfalls ein GROUP BY und vorne ein COUNT(DISTINCT spalte)
- noisefloor
- User
- Beiträge: 3843
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
es hört sich so an, als ob das einer einer verteilen Datenbank ruft, wo dann die Ergebnisse per MapReduce erfasst und zusammengefasst werden (Google macht das auch so ).
Dann bist du aber ziemlich weit weg von SQLite & Co, weil du dann ein verteiltes DBMS wie Hadoop oder so brauchst - und mehrere DB Server...
Was mir noch einfällt: Die "großen", kommerziellen DBMS wie Oracle kennen AFAIK auch vertikalen und horizontale Tabellenteilungen, um die DB auf mehrere Rechner zu verteilen. In wie fern die freien Version von Oracle & Co das Unterstützen weiß ich nicht...
Gruß, noisefloor
es hört sich so an, als ob das einer einer verteilen Datenbank ruft, wo dann die Ergebnisse per MapReduce erfasst und zusammengefasst werden (Google macht das auch so ).
Dann bist du aber ziemlich weit weg von SQLite & Co, weil du dann ein verteiltes DBMS wie Hadoop oder so brauchst - und mehrere DB Server...
Was mir noch einfällt: Die "großen", kommerziellen DBMS wie Oracle kennen AFAIK auch vertikalen und horizontale Tabellenteilungen, um die DB auf mehrere Rechner zu verteilen. In wie fern die freien Version von Oracle & Co das Unterstützen weiß ich nicht...
Gruß, noisefloor