Select Abfrage einmalig langsam

[jobo]

Zitat von Dr. Jack:

Es muss irgendetwas in der Programmierung sein. Leider komme ich nicht drauf

Dann zeig doch mal irgendwas von Deinem Programmcode, dann kommen wir bestimmt drauf.


Deja Vu, Phänomen kommt mir bekannt vor, Thema auch.

Alle Datasets/Queries ungefiltert zum Programmstart öffnen, das kann solche Effekte haben. Erst Recht, wenn die ein oder andere komplexe Quuery dabei ist.

So oder so, man macht es nicht. Das würde ich unter Konzeptfehler laufen lassen.

[Delphi.Narium]

Wenn 'ne Datenbank 'ne Abfrage macht, muss sie die Daten erstmal vom Datenträger lesen.

Je nach "Intelligenz" des Datenbanksystems und des darunter liegenden Betriebssystems, befinden sich dann mehr oder weniger viele der Daten im Cache. Deshalb sind nachfolgende (und weitgehend identische) Operationen für gewöhnlich schneller, als der erste "Anlauf". Das ist eigentlich ein vollkommen normales Verhalten.

Wenn man nun beachtet, das erstens die Festplatten über 'nen Cache verfügen, dann das Betriebssystem 'nen eigenen Cache vorhält, ja nach Datenbank diese ebenfalls gelesene Daten cached, dazu das Betriebssystem des Clients noch was cached, können da schonmal deutliche Zeitunterschiede bei rauskommen.

Und gerade bei dateibasierten Systemen kann hier ein sehr deutlicher Zeitunterschied entstehen, insbesondere dann, wenn man die Daten auch noch übers Netzwerk holt.

Mach mal für ein größeres Verzeichnis auf der Kommandozeile ein dir *.* /s und stoppe die Zeit. Und dann machst Du das sofort nochmal. Du wirst dann auch dabei einen Zeitunterschied feststellen. Beim ersten Mal muss das Verzeichnis von der Platte gelesen werden, beim zweiten "Anlauf" wird's aus dem Cache gelesen und damit liegt das Ergebnis deutlich schneller vor.

Das Ganze hängt dann noch von den Größen der jeweiligen Caches ab, so dass auf unterschiedlich konfigurierten Systemen auch da noch unterschiedliche Zeiten bei rauskommen, selbst dann, wenn technisch Hardware, Betriebssystem, Datenbanksystem und Clientsoftware übereinstimmen.

Es gibt da vielzuviele Schrauben, an denen man was drehen kann, um bei erstmaliger, langer Laufzeit direkt auf 'nen Implementierungsfehler, der nach Beseitigung das Problem aus der Welt schafft, hoffen zu können.

Und hhcms Hinweis ist absolut korrekt. Bei SQLite wird zuerst mal die Datenbankdatei über das Netzwerk gelesen, sie befindet sich dann im Arbeitsspeicher Deines Rechners (und notfalls (teilweise) in der Auslagerungsdatei Deines Rechners). Der Zugriff dadrauf ist einfach schneller, als das erstmalige Lesen der Datei übers Netz.

Es wäre fast schon verwunderlich, wenn der erste Zugriff genauso schnell wäre, wie die nachfolgenden Zugriffe. Das würde nämlich bedeuten, dass sämtliche Anstrengungen, die für die Implementierung der Caches (die der Beschleunigung wiederholter Lese- und Schreibzugriffe dienen) gemacht wurden, für die Katz wären.

[Dr. Jack]

OK danke für deine Erklärung.
Ich dachte eigentlich, dass nur die angefragten Daten, also lediglich ein paar Kilobyte, über das Netzwerk geschickt werden und nicht die ganze Datei. Die ist tatsächlich 130 Megabyte groß.
Dann ist es natürlich nicht verwunderlich dass er ca 10 Sekunden braucht um es im RAM zu catchen.
Vielleicht wäre eine Möglichkeit, dass man beim Programmstart erstmal die Datei in den RAM im Hintergrund holt und eine Art Countdown für den User macht.
Oder kann ich das eventuell ändern, dass ich tatsächlich nur die Daten hole, die ich Abfrage? Nehmen wir an dass die Datenbank auf einige Gigabyte wächst, dann wäre das doch eine einzige Katastrophe wenn sie erst geladen werden würde?!
Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

[jobo]

Zitat von Dr. Jack:

Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

Gute Gedanken!

SQLite ist tatsächlich für den lokalen Gebrauch gedacht und bringt diese Effekte mit sich. Viele andere gängige SQL Server sind echte Server und bringen durch ihre Installation genau das mit, was Du als "Requester" bauen möchtest. Davon will ich Dich natürlich nicht abhalten, aber:

Installier Dir z.B. Firebird oder Postgres auf irgendeinem Rechner (zunächst tut's der Entwicklungsrechner) und jeder Client holt per SQL nur die Datenmenge aus der DB, die die Abfrage liefert.
Mit Firebird hättest Du noch das Feature, dass es kompatibel zum "großen Bruder" auch als embedded System lokal eingesetzt werden kann, als Singleusersystem (falls das tatsächlich ein Bedarf ist).

[jobo]

Und nicht oft genug:

Zitat von jobo:

.. Viele andere gängige SQL Server sind echte Server und bringen durch ihre Installation genau das mit, was Du als "Requester" bauen möchtest. Davon will ich Dich natürlich nicht abhalten, aber:

Installier Dir z.B. Firebird oder Postgres auf irgendeinem Rechner (zunächst tut's der Entwicklungsrechner) und jeder Client holt per SQL nur die Datenmenge aus der DB, die die Abfrage liefert.
...

[Delphi.Narium]

Sagen wir mal so: Für 'ne Datenbankanwendung sollte man 'ne Datenbank nutzen.

SQLite ist für mich genausowenig 'ne Datenbank, wie damals dBase oder Paradox per BDE. Ja das ging für 'nen Einzelplatz und nicht so übermäßig große Datenmengen oder ein reines Auskunftssystem. SQLite mag auch für das Speichern der Konfiguration des FireFox (oder ähnlichem) gut sein, aber 'nen Mehrbenutzerbetrieb mit 'ner im Netz liegenden Datei halte ich für suboptimal (oder eher absoult abwegig).

Wer auf so 'ne Idee kommt, sollte sich erstmal grundlegend mit dem Sinn und Zweck von Datenbanken beschäftigen und sich Grundlagenwissen verschaffen. Warum haben wohl 1000de Entwickler über Jahrzehnte Hirnschmalz und Manpower in die Entwicklung von Datenbankservern gesteckt, wenn man die gleiche Leistung auch mit 'ner eingebundenen DLL und 'ner Datei irgendwo im Netz hinbekommt?

Die Tatsache, dass man mit 'ner dateibasierten "Datenbank" das irgendwie hinbekommen kann, ist nicht gleichbedeutend mit: "Das ist ein sinnvolles Vorgehen."

[rokli]

Hallo,

und selbst Microsoft gibt Dir die SQL kostenlos (Developer Version) - oder schau mal nach SQLExpress, auch die hat für kleine Datenmengen nur minimale Einschränkungen gegenüber einer gekauften MS SQL DB, bei der Du dann auch die Clients anschaffen musst.

Gruß

[Bernhard Geyer]

Zitat von Dr. Jack:

Oder kann ich das eventuell ändern, dass ich tatsächlich nur die Daten hole, die ich Abfrage? Nehmen wir an dass die Datenbank auf einige Gigabyte wächst, dann wäre das doch eine einzige Katastrophe wenn sie erst geladen werden würde?!
Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

oder du nimmst einfache einen der "üblichen" Verdächtigen wie MySQL, MS SQL Server, Oracle, Firebird und Co. und lässt diesen SQL-Servern genau das machen.
Dafür wurden diese u.A. auch entwickelt um genau das zu machen.

[p80286]

Zitat von Bernhard Geyer:

Zitat von Dr. Jack:

Oder kann ich das eventuell ändern, dass ich tatsächlich nur die Daten hole, die ich Abfrage? Nehmen wir an dass die Datenbank auf einige Gigabyte wächst, dann wäre das doch eine einzige Katastrophe wenn sie erst geladen werden würde?!
Oder ich baue eine Art Requesterprogramm für den Server. Der organisiert den Datentransfer. Mit den Gedanken werde ich mich mal beschäftigen...

oder du nimmst einfache einen der "üblichen" Verdächtigen wie MySQL, MS SQL Server, Oracle, Firebird und Co. und lässt diesen SQL-Servern genau das machen.
Dafür wurden diese u.A. auch entwickelt um genau das zu machen.

man kann es nicht groß genug schreiben!
Gruß
K-H

[MichaelT]

Nehme eine der üblichen Verdächtigen. Es gibt davon genug.

--

Es gibt eine Datenbank namens cubeSQL (SQLite based 'Server').

Aber meine letzten Erfahrungen die DB an Delphi anzubinden waren eher ernüchternd. Die DB selbst ist wofür sie gemacht wurde ganz in Ordnung. Aber ohne eine sauber implementierten Nativetreiber ... der Aufwand steht nicht dafür.

Zitat von p80286:

Zitat von Bernhard Geyer:

oder du nimmst einfache einen der "üblichen" Verdächtigen wie MySQL, MS SQL Server, Oracle, Firebird und Co. und lässt diesen SQL-Servern genau das machen.
Dafür wurden diese u.A. auch entwickelt um genau das zu machen.

man kann es nicht groß genug schreiben!
Gruß
K-H