SQLite plattgemacht ;-)
-
Aus Bosheit lote ich gerade mal aus was SQLite so kann.
Quelldaten: csv, ca 34 Mio Sätze, 3.5 GB
Ich habe versucht, die csv-Datei mittels des SQLite-Managers (Firefox-Plugin)
zu importieren, der legt einfach die Ohren an und macht eher NICHTS.Also mal schnell ein Programm geschrieben was mir die Daten einliest, ich
wollte die mir dann über das Web ansehen. Nach einigen Stunden war die Datenbank
aufgebaut - anzeigen konnte ich sie nicht. Anscheinend hat der Apache einen
timeout, nach ca 5 min killt er die Applikation (in diesem Fall ein select
count(*).Irgendwie scheine ich da eine Grenze überschritten zu haben
PS: Seit 1,5 h erstellt es einen Index ... (Quadcore 2,8 MHz)
-
2,8 MHz
das erklärt einiges...
-
Was erwartest du dir bei der Abfrage select count(*) von einem Index?
-
Zebald schrieb:
Was erwartest du dir bei der Abfrage select count(*) von einem Index?
Die Anzahl der vorhandenen Records - was sonst.
Die Abfrage ist nicht wichtig, halt mal probiert. Er erstellt immer noch
den Index.
-
Aggregierungen (z.B. count, sum) über alles in einer Tabelle sind eigentlich Beispiele, wo ein Index nichts bringt.
Edit: Was mich noch interessieren würde: Wie groß ist das SQLLite-File?
-
Also count(*) sollte eine Datenbank "so" können.
Und bei sum() kann ein Index schon was bringen, nämlich wenn die Tabelle relativ breit ist und der Index relativ schmal, aber ausreicht um die Abfrage durchzuführen (=alle nötigen Spalten enthält).
Wobei ich nicht weiss ob SQLite nen Index so verwenden kann (SQL Server kann es).
-
sqlite ist einfach nicht webscale
-
Zebald schrieb:
Wie groß ist das SQLLite-File?
3,81 GB (4.101.040.128 Bytes) lt. "Eigenschaften" (Größe Auf Datenträger 3,81 GB (4.101.042.176 Bytes)). Der Windows-Explorer zeigt 4.004.922 KB.
Also in dieser Gegend ...
-
brogram schrieb:
sqlite ist einfach nicht webscale
Was meinst Du damit ?
-
das sqLITE nicht fürs web gemacht ist, sondern für andere dinge
-
vario-500 schrieb:
das sqLITE nicht fürs web gemacht ist, sondern für andere dinge
Es funktioniert aber wirklich gut. Nur ab ca 5 Mio Records wird es etwas
langsam (muß ich noch mal genauer testen). SQLite habe ich im Live-Betrieb
laufen. Die Kunden sind zufrieden.Problematisch sind halt größere Datenmengen >100 GB / Jahr.
Der Kunde wo ich da probiert habe, wird pro Jahr >200 Mio Records haben.
Es war halt mal ein Versuch. Im Moment habe ich da eine selbsgebaute DB
laufen.Ich habe das mit Kollegen besprochen - alle meinten dafür braucht's einen
Oracle-Cluster
-
Scheppertreiber schrieb:
vario-500 schrieb:
das sqLITE nicht fürs web gemacht ist, sondern für andere dinge
Es funktioniert aber wirklich gut. Nur ab ca 5 Mio Records wird es etwas
langsam (muß ich noch mal genauer testen).Könnte das vielleicht genau die Grenze sein wo der File-Cache nimmer ausreicht um die relevanten Teile der DB vorrätig zu halten?
Problematisch sind halt größere Datenmengen >100 GB / Jahr.
Problematisch sind Abfragen die zu viele IOs brauchen um ausgeführt zu werden, ganz egal wie man zu diesen IOs kommt.
Und genau da schraubt man dann auch: entweder man kauft sich mehr IOs/Sekunde, oder man guckt dass man weniger IOs/Sekunde braucht.
Dafür braucht es dann oft ne schlauere Datenbank als SQLite, oder man muss es zu Fuss programmieren.Aber zurück zum Thema SQLite: welche Einstellungen verwendest du?
-
Aber zurück zum Thema SQLite: welche Einstellungen verwendest du?
Ich habe es ma bei den Standardeinstellungen belassen.
Die Applikation archiviert und stellt die Zettel über das Web zur Verfügung.
Mit dem üblichen Rattenschwanz an Zugriffsrechten die man kaum noch über DBs
abbilden kann, vielen kundenspezifischen Gimmicks und Zertifikaten.Verarbeitet werden Streamdaten (Text, XML *bäh*) und PDF/TIFF. Zur Ausgabe werden
die PDF entweder ausgeliefert oder on-the-fly erzeugt. Die Dokumente kann
der Kunde auch auf eine CD/DVD mit Abfrageprogramm bekommen (uA der Grund
für SQLite - ich kann es für alles nehmen).Bei einem großen Kunden sind das knapp 500 GB pro Jahr.
Bei kleineren Kunden hat sich SQLite prima bewährt. Flexibel (halt SQL) und
einfach anwendbar, es sind dadurch noch einige WorkFlow-Anwendungen dazu
gekommen.Vorteile SQLite:
* keine Installation oder Pflege notwendig
* alle Platformen
* die beiden Admins die sich um die Systeme kümmern haben Zeit für WichtigeresProblematisch ist, ich muß irgendwo eine Grenze ziehen die sich durch eine
erträgliche Performance SQLite ergibt. Da versuche ich mich heranzutasten.Mit SQLite3.exe kann ich mein 3-Mio-Records-Monster abfragen, es dauert aber ...
Die Sache mit dem Cache müsste man mal genauer beobachten. Ich habe ja immer
noch im Hinterkopf, alles auf Linux umzuheben (in C ja machbar) und mich um
Caching nicht gekümmert. Im Moment laufen die Server und XP prof.Compiler: Watcom C, nix PHP oder so.
-
Und Indexe etc. passt alles?
-
hustbaer schrieb:
Und Indexe etc. passt alles?
Weitestgehend
Wie es so schön heißt: Immer Platz für Optimierungen ...
Im Moment lese ich mal in mein System 40 GB Daten ein und vergleiche das mal.
-
MongoDB
-
Soderle, schlaffe 36 GB Daten sind importiert (in meine Eigenkonstruktion).
Es paßt nicht alles auf meinen Server, also nur 1 Monat. Die Suchzeiten sind
dramatisch kleiner (ich habe ja auch alles rausgeworfen was nicht unbdedingt
notwendig ist).Quelle: XML-Daten mit assoziierten PDF, insgesamt 9.615.069 Datensätze /
PDF. Ist 2 Tage gelaufen. Suchzeiten incl. Ausgabe als HTML/CSV, Excel in
1 sec bei 100 Treffern. Wäre nicht die Zeit um das über den Webserver zu
jagen wäre ich noch mehr zufrieden
-
Hallo, mal dumm gefragt, wäre es aber bei der Menge an Daten nicht eventuell eine Überlegung wert auf andere DB's zurück zu greifen z. B. PostgreSQL, MySQL, etc...?
-
guenni81 schrieb:
Hallo, mal dumm gefragt, wäre es aber bei der Menge an Daten nicht eventuell eine Überlegung wert auf andere DB's zurück zu greifen z. B. PostgreSQL, MySQL, etc...?
Mir wurde berichtet, ein Oracle-Cluster hätte da auch dran zu kauen ...
-
Scheppertreiber schrieb:
Mir wurde berichtet, ein Oracle-Cluster hätte da auch dran zu kauen ...
Ich behaupte mal das kommt wohl auch auf die größe des Clusters an.
