Hallo,

Es wäre sicherlich sinnvoller, das nicht insgesamt „in den Hauptspeicher zu ‚cachen‘“, sondern zum Beispiel in der Binärdatei vorne einen Index einzufügen, welcher Inhalt an welchem Offset liegt, diesen Index auszulesen, dann direkt zum passenden Offset zu springen und noch mal das auszulesen, was benötigt wird.

...womit man grundsätzlich wieder so etwas ähnliches wie eine Datenbank baut. Aber ich gebe Dir grundsätzlich recht. Man müsste sich zwar das Verhalten im Einzelnen anschauen (nachdem das Betriebssystem ja i.d.Regel nicht Bitweise sondern Blockweise liest, kann es ggf. sein, dass es ohnehin einen Großteil der Daten bereits "auf den ersten Rutsch" hin einliest, und es somit keinen Unterschied macht), aber ich würde auch erstmal vermuten, dass das effizienter ist.
Wobei eine andere Möglichkeit eben auch wäre, beim Start des Servers EINMALIG sämtliche Daten in den Arbeitsspeicher zu laden und dort zu halten. Dann werden bei jedem Request die Daten immer direkt aus dem Arbeitsspeicher geladen, und man benötigt überhaupt keinen Plattenzugriff mehr. Je nach Anwendungsszenario kann ich mir das schon sinnvoll vorstellen.

Eine Datenbank wird ja immer dann interessant, wenn Du genau das (also das Laden sämtlicher Daten in den Speicher) mangels genug Arbeitsspeicher eben nicht mehr bewerkstelligen kannst und gezeilt einzelne Daten abfragen musst.

Das ist für meinen Geschmack dann aber doch einen Tick zu pauschal formuliert. Datenbanken werden doch nicht deshalb genutzt, weil einem sonst der Speicher ausgeht.

Das habe ich auch nicht behauptet. Aber wenn es um Performance geht (und darum ging es hotti ja), ist der Arbeitsspeicher der Applikation grundsätzlich unschlagbar. Wenn die Daten erstmal alle im Speicher liegen, ist ja auch eine Arbeit auf diesen Daten ein Leichtes. Filtern, Sortieren, usw. - das ganze dauert im Arbeitsspeicher ein paar Zyklen, also Peanuts.

So lange Du aber alles in den Hauptspeicher lädst, wird ein Flatfile IMMER schneller sein als eine Datenbank.

Auch das möchte ich vorsichtig bezweifeln beziehungsweise um Klärung bitten, was du da im Detail vergleichst.

Ich gehe von einer frisch gestarteten Datenbank aus.
Wenn ich ALLE Daten aus einem Flatfile lese, dauert es so lange, wie eben das physische Einlesen von der Platte dauert.
Wenn ich ALLE Daten aus einer Datenbank lese (SELECT * FROM... or whatever), so muss die Datenbank

• Meinen Datenbank-User authentifizieren
• Meine Abfrage ("SELECT * FROM...") parsen
• Die Rechte für diese Abfrage prüfen
• Einen Ausführungsplan erstellen (gut sollte in dem Fall trivial sein, also full-table-scan)
• Die benötigten Datensegmente bestimmen und diese von der Platte in den Arbeitsspeicher laden
• Eine Antwort zusammenbauen und diese wieder an meine Anwendung schicken.

Das KANN also schonmal nicht so schnell sein, wie wenn ich es direkt aus einer Datei lade.
Was anderes ist es natürlich, wenn ich dieselbe Abfrage MEHRFACH stelle. Hier kann man davon ausgehen, dass die Datenbank das Abfrageergebnis in irgendeiner Form cached, sprich, das Ergebnis bereits im Arbeitsspeicher vorliegen habe.
Wenn ich aber beim Start der Applikation EINMALIG (also nicht bei jedem Request) ALLE Daten in den Arbeitsspeicher lade, so muss das Flatfile zwangsläufig schneller sein.

Den Overhead für das Aufbauen einer Verbindung kann man übrigens dadurch reduzieren, dass man die Datenbankverbindung offen lässt.

Das muss trotzdem auch erst mal keine 70 ms dauern. Mit PHP und mysqli bin ich für einen Verbindungsaufbau zeitlich zum Beispiel in einer Größenordnung, in der es schon fast keinen Sinn mehr ergibt, das überhaupt zu messen (3-7 ms).

70ms kommt mir auch sehr viel vor, aber dazu müsste man mehr über das Setup wissen. Welche Datenbank, welcher Datenbank-Treiber (in Perl, was hotti verwendet, gibt es ja z.b. C und Perl-Implementierungen, letztere ist m.E. etwas langsamer), ob die Datenbank auf derselben Maschine liegt wie die Applikation, was auf der Kiste sonst noch alles läuft etc.

Jedenfalls ist es in den größeren Plattformen, in denen ich mich berufsbedingt herumtreibe, üblich, Connection Pools zu verwenden, weil da der Overhead für den Verbindungsaufbau sehr wohl ins Gewicht fällt.

Viele Grüße,
Jörg