Hallo!
Ich Arbeite derzeit mit einer sqlite Datenbank. In dieser hab ich eine Tabelle, welche mehr als 330 Millionen Einträge hat. Jetzt muss ich hier aber öfter auf diese Daten zugreifen. Dies dauert aber eine Ewigkeit. Gibt es hier irgendeine Möglichkeit dies deutlich zu beschleunigen?
Danke und lg
Philipp
Sehr große Datenbank
Ah okay. Und wie mach ich das dann genau?
Nehmen wir an die Tabelle schaut so aus:
id text other_id
Meine Abfragen beschränken sich immer auf eine "Where other_id = ???" Klausel.
D.h. ich amche jetzt folgendes:
CREATE UNIQUE INDEX the_index ON tbale_name (other_id)
Und meine WHERE Abfragen lasse ich gleich.
Wäre das so korrekt?
lg
Nehmen wir an die Tabelle schaut so aus:
id text other_id
Meine Abfragen beschränken sich immer auf eine "Where other_id = ???" Klausel.
D.h. ich amche jetzt folgendes:
CREATE UNIQUE INDEX the_index ON tbale_name (other_id)
Und meine WHERE Abfragen lasse ich gleich.
Wäre das so korrekt?
lg
- noisefloor
- User
- Beiträge: 3882
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
IMHO ist 330 Mio Einträge nichts, wo SQLite auch nur annähernd performant läuft - Index hin oder her.
Für "große" Aufgaben sollten die "großen" DBs wie MySQL, PostgreSQL etc. besser geeignet sein, weil die auch für "große" Tabellen ausgelegt sind. Wobei: 330 Mio ist schon echt viel...
Wenn die DB nur eine Tabelle hat, dann solltest du mal einen Blick auf ein Key-Value-Store werfen wie Redis oder Tokyo Cabinate oder Keyscale oder ... Die sind bei dann wesentlich performanter.
IMHO ist 330 Mio Einträge nichts, wo SQLite auch nur annähernd performant läuft - Index hin oder her.
Für "große" Aufgaben sollten die "großen" DBs wie MySQL, PostgreSQL etc. besser geeignet sein, weil die auch für "große" Tabellen ausgelegt sind. Wobei: 330 Mio ist schon echt viel...
Wenn die DB nur eine Tabelle hat, dann solltest du mal einen Blick auf ein Key-Value-Store werfen wie Redis oder Tokyo Cabinate oder Keyscale oder ... Die sind bei dann wesentlich performanter.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo!noisefloor hat geschrieben:IMHO ist 330 Mio Einträge nichts, wo SQLite auch nur annähernd performant läuft - Index hin oder her.
Was das betrifft, interessiert mich die von mir heiß ersehnte Antwort von Killver, ob und wieviel der Index an Geschwindigkeit gebracht hat. Denn mit so großen SQLite-Datenbanken hatte ich es auch noch nicht zu tun.
mfg
Gerold
EDIT: Die Frage ist nicht "ob", sondern nur "wieviel" der Index gebracht hat.
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.
- noisefloor
- User
- Beiträge: 3882
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
ja, mich auch. Zumal 330 Mio echt viel ist... Wenn ich mich recht erinnere habe ich mal für MySQL gelesen, dass die damit "angeben" , dass MySQL bei Tabellen mit 60 Mio Zeilen noch performant ist. Nun, hier haben wir aber 4x mehr.
BTW: wie lange dauert denn eine Abfrage mit SQLite auf die 330 Mio Tabelle? Ich vermutet, wir reden über ein paar Sekunden?
Und dann werfe ich noch das Stichwort Partitionierung von Tabellen in die Runde.
Gruß, noisefloor
ja, mich auch. Zumal 330 Mio echt viel ist... Wenn ich mich recht erinnere habe ich mal für MySQL gelesen, dass die damit "angeben" , dass MySQL bei Tabellen mit 60 Mio Zeilen noch performant ist. Nun, hier haben wir aber 4x mehr.
BTW: wie lange dauert denn eine Abfrage mit SQLite auf die 330 Mio Tabelle? Ich vermutet, wir reden über ein paar Sekunden?
Und dann werfe ich noch das Stichwort Partitionierung von Tabellen in die Runde.
Gruß, noisefloor
- noisefloor
- User
- Beiträge: 3882
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Gruß, noisefloor
Ich habe das gerade nochmal nachgerechnet - im Kopf und per Skript - und einen Unit-Test drüber laufen lassen. Wir reden über einen Faktor von 5, nicht 4...noisefloor hat geschrieben:dass MySQL bei Tabellen mit 60 Mio Zeilen noch performant ist. Nun, hier haben wir aber 4x mehr
Gruß, noisefloor
Ich hoffe du hast das nochmal in die QA gegeben und von einem weiteren Entwickler prüfen lassen!noisefloor hat geschrieben:Hallo,
Ich habe das gerade nochmal nachgerechnet - im Kopf und per Skript - und einen Unit-Test drüber laufen lassen. Wir reden über einen Faktor von 5, nicht 4...noisefloor hat geschrieben:dass MySQL bei Tabellen mit 60 Mio Zeilen noch performant ist. Nun, hier haben wir aber 4x mehr
Gruß, noisefloor
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Und die Buchhaltung hat das hoffentlich auch nochmal ueberprueft!jbs hat geschrieben:Ich hoffe du hast das nochmal in die QA gegeben und von einem weiteren Entwickler prüfen lassen!
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo!gerold hat geschrieben:Was das betrifft, interessiert mich die von mir heiß ersehnte Antwort von Killver
Killver? Hast du den Index ausprobiert?
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.
Sorry Leute, hatte das Thema aus den AUgen verloren.
Ja es hat sehr viel gebracht.
Ich habe aber meine Datenbank wieder über den Haufen geworfen und werde jetzt dann nochmal viel mehr Einträge haben. Ich berichte dann wie viele und opb es performant ist
lg
Ja es hat sehr viel gebracht.
Ich habe aber meine Datenbank wieder über den Haufen geworfen und werde jetzt dann nochmal viel mehr Einträge haben. Ich berichte dann wie viele und opb es performant ist
lg
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
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
- 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)