Sehr große Datenbank

[Killver]

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

[marlob]

Hast du Indexe für deine Tabellen erzeugt?

[Killver]

Was meinst du damit genau?

[BlackJack]

@Killver: Na Indexe halt. Wenn Du keine für die für die Abfrage relevanten Daten angelegt hast, muss die Datenbank ja im schlimmsten Fall bei jeder Anfrage alle 330 Millionen Datensätze prüfen -- das dauert halt.

[Killver]

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

[BlackJack]

@Killver: Das sieht soweit okay aus.

[noisefloor]

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.

[gerold]

IMHO ist 330 Mio Einträge nichts, wo SQLite auch nur annähernd performant läuft - Index hin oder her.

Hallo!

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.

[noisefloor]

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

[noisefloor]

Hallo,

dass MySQL bei Tabellen mit 60 Mio Zeilen noch performant ist. Nun, hier haben wir aber 4x mehr

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...

Gruß, noisefloor

[jbs]

Hallo,

dass MySQL bei Tabellen mit 60 Mio Zeilen noch performant ist. Nun, hier haben wir aber 4x mehr

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...

Gruß, noisefloor

Ich hoffe du hast das nochmal in die QA gegeben und von einem weiteren Entwickler prüfen lassen!

[cofi]

Ich hoffe du hast das nochmal in die QA gegeben und von einem weiteren Entwickler prüfen lassen!

Und die Buchhaltung hat das hoffentlich auch nochmal ueberprueft!

[BlackJack]

Ich hoffe alle beteiligten Firmen/Organisationen sind ISO 9001 zertifiziert!?

[gerold]

Was das betrifft, interessiert mich die von mir heiß ersehnte Antwort von Killver

Hallo!

Killver? Hast du den Index ausprobiert?

mfg
Gerold

[Killver]

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

[Killver]

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

[Käptn Haddock]

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

[Killver]

RAM sollten ausreichend sein. Abfragen auf eine einzelne Tabelle, die viel viel größer ist, gehen auch deutlich flotter.

Andere Datenbank ist leider keine Alternative.

[gerold]

Bei größeren Daten dauert die Abfrage aber unglaublich lange.

Hallo Philipp!

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

[Killver]

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)