Select Abfrage einmalig langsam

[Dr. Jack]

Hallo zusammen,

wenn ich eine Selecte absetze, dauert es einmalig bis zu 10 Sekunden, bevor die Daten geladen sind.
Aber das ist nur einmalig bei der ersten Abfrage nach Programmstart. Die nächsten Anfragen laufen dann wieder in gewohnter Geschwindigkeit.
Was kann das sein?

[jobo]

Vielleicht einfach die 10 Sekunden, die es braucht, um die Datei lokal zu cachen.
Wenn Du etwas mehr zum Setup schreibst, müssen andere weniger raten. (Device/Plattform, Netz, Größe, Anzahl Datensätz, ..)

[p80286]

Auf SQLite über Firebird zugreifen?
10 sec halte ich für eine lokale DB für sehr viel.....

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1425436)

Auf SQLite über Firebird zugreifen?

Sollte das nicht FireDAC heißen? Oder habe ich was verpasst?

[Dr. Jack]

Zitat:

Zitat von Uwe Raabe (Beitrag 1425437)

Zitat:

Zitat von p80286 (Beitrag 1425436)

Auf SQLite über Firebird zugreifen?

Sollte das nicht FireDAC heißen? Oder habe ich was verpasst?

jo tatsächlich. danke

[Dr. Jack]

das Ganze läuft über ein Netzlaufwerk (win 2008 Server), Client in ein win7 Rechner, Netzwerkgeschwindigkeit.
ca. bis 4 Gbit, je nach Auslastung. Es muss irgendetwas in der Programmierung sein. Leider komme ich nicht drauf

[Bernhard Geyer]

Wie groß ist die DB und werden Indexes verwendet?
Initial muss viel Daten über das Netzwerk übertragen werden.
Beim zweiten mal liegen diese schon im Windows-Dateicache vor und es geht viel schneller.

[jobo]

Zitat:

Zitat von Dr. Jack (Beitrag 1425443)

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.

[hhcm]

Zitat:

Zitat von Dr. Jack (Beitrag 1425443)

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

Eigentlich nicht. Das "Problem" hatte ich auch schonmal, dabei war es nur ein Denkfehler. Eine SQLite Datenbank ist nunmal eine Dateibasierte Datenbank.
Es gibt keinen Server der über´s Netzwerk mit Daten antwortet.
Öffnest du die SQLitedatenbank, so wird die komplette SQLite Datei über´s Netzwerk Lokal gecached. Dann machst du dein Query und es kommen Daten.
Selbes Query erneut - (Datei muss nicht mehr kopiert werden) - Schnelleres Ergebnis.

[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:

Zitat von Dr. Jack (Beitrag 1425469)

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

[Bernhard Geyer]

Zitat:

Zitat von Dr. Jack (Beitrag 1425469)

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:

Zitat von Bernhard Geyer (Beitrag 1425474)

Zitat:

Zitat von Dr. Jack (Beitrag 1425469)

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

[jobo]

Und nicht oft genug:

Zitat:

Zitat von jobo (Beitrag 1425470)

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

[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:

Zitat von p80286 (Beitrag 1425514)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1425474)

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

[TigerLilly]

Zitat:

Zitat von rokli (Beitrag 1425526)

oder schau mal nach SQLExpress, auch die hat für kleine Datenmengen nur minimale Einschränkungen gegenüber einer gekauften MS SQL DB

Wobei "Einschränkungen" sehr großzügig zu verstehen ist. Die Max-Größe pro DB ist mit 10 GB beschränkt + es werden nur 4 Prozessorkerne unterstützt. Dann gibt es noch Einschränkungen bei Failover + Verschlüsselung. Aber wer sowas braucht, denkt eh gar nicht an Express.

Siehe hier: https://www.microsoft.com/de-de/sql-...-2017-editions

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1425593)

Die Max-Größe pro DB ist mit 10 GB beschränkt + es werden nur 4 Prozessorkerne unterstützt. Dann gibt es noch Einschränkungen bei Failover + Verschlüsselung.

Wir reden hier über ein brauchbares Replacement für eine SQLite DB auf einem Netzlaufwerk!

[TigerLilly]

Ja, da sind diese Einschränken völlig irrelevant, das meinte ich.