Was macht Datenbanken so schnell?

[Matze]

Hallo zusammen,

im Endeffekt sind Datenbanken doch nichts anderes als Dateien, die auf Festplatten liegen. Dennoch sind Datenbanken deutlich schneller, als wenn Schreib- und Lesezugriffe manuell über Dateizugriffe erfolgen würden.

Was macht den Datenbanken so schnell?

Folgendes könnte ich mir vorstellen:

• Suchanfragen werden durch verschiedene Indizes beschleunigt (gut, das ist Fakt)
  Wobei die Indizes wohl auch in Dateien abgelegt sind, auf die zugegriffen werden muss.
• Lesevorgänge könnten schnell sein, wenn die Datenbank eine gewisse Intelligenz aufweist und vorab einige Dinge im RAM puffert und aus diesem ausliest.
  Aber das kann bei großen Datenmengen nicht sein. Gut, die Indizes könnten teilweise im RAM gepuffert werden.
• Schreibzugriffe auf Dateien sind eigentlich nur dann flott, wenn eine Datei einmalig geöffnet wird und sämtliche Schreibzugriffe dann erfolgen, da die Betriebssysteme hier die Daten im RAM puffern und die Festplatte ebenfalls in ihrem Cache. Bei einem Absturz wären die Daten jedoch verloren, wenn die Datei nicht zuvor geschlossen wurde.
  Und bei Datenbanken sind die Daten nach dem Schreibvorgang zuverlässig vorhanden.

Was also macht Datenbanken so schnell? :gruebel:

Grüße, Matze

[mirage228]

Du glaubst gar nicht wie sehr Indices in Datenbanken sich auf die Lese(!)-Geschwindigkeit auswirken können. Wenn Du als Extrembeispiel Column Stores (Datenbanken mit spaltenbasierter physischer Speicherung, oft für BI verwendet) nimmst, können diese eine riesige Menge an Daten von vorne Weg über einfache Mengenoperationen auf Indices ausschließen (z.B. in dem einfach Bit-Vektoren mit AND oder OR verknüpft werden) sodass die Zeit für eine aufwendige Suche entfällt. Solche Bitvektoren sind so klein, dass sie in einem Rutsch teilweise von der Festplatte eingelesen werden können oder sogar im Arbeitsspeicher verweilen. Einige passen auch komplett oder teilweise in den CPU-Cache hinein. Dann wird es sehr schnell :mrgreen:

Außerdem können Datenbanken beim Schreiben von mehreren Puffern Gebrauch machen sowie - für den Benutzer unsichtbar im Hintergrund - von RAID-Verbünden und somit auf viele Datenträger verteilten Anfragen.

Das mal so grob zusammengefasst. :)

Als Lektüre dazu vielleicht noch interessant:

Viele Grüße

[hoika]

Hallo,

hast es ja schon fast alles alleine beantwortet ;)

Zitat:

Bei einem Absturz wären die Daten jedoch verloren, wenn die Datei nicht zuvor geschlossen wurde

Es gibt FlushBuffers (heisst bei NTFS nat. anders),
dann werden nur die geänderten Bereiche geschrieben,
die DB bleibt offen.


Heiko

[Uwe Raabe]

Hinzu kommt ja meistens auch noch, daß die Datenbank-Software exklusiven Zugriff auf die Datei(en) hat und sich nicht mit anderen Anwendungen darum streiten muss.

[Matze]

Danke für die Antworten.

Dann ist es an sich gar nichts so ungewöhnliches. Ich habe nun ein super tolles Verfahren dahinter erwartet. *g*

[H4ndy]

Zitat:

Zitat von Matze

Ich habe nun ein super tolles Verfahren dahinter erwartet. *g*

Die super tollen Verfahren liegen in der hochgradigen Optimierung, um moeglichst wenig auf der Festplatte machen zu muessen.
Dazu kommt noch geschicktes Parsen und verteilen der Daten in den Dateien bzw. auf der Festplatte.

[alzaimar]

Zitat:

Zitat von H4ndy

...hochgradigen Optimierung, um moeglichst wenig auf der Festplatte machen zu muessen.

a.k.a. Cache.

Zitat:

Zitat von H4ndy

Dazu kommt noch geschicktes Parsen

eher nicht, unbedeutend.

Zitat:

Zitat von H4ndy

und verteilen der Daten in den Dateien bzw. auf der Festplatte.

und ich dachte, der Cache wäre so wichtig (also gerade wenig File I/O.

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von H4ndy

Dazu kommt noch geschicktes Parsen

eher nicht, unbedeutend.

Es ist bedeutent, wenn sich der Query Analyser "verrennt". Wir haben die Erfahrung damit das dies des öfteren bei Oracle passiert das dieser den falschen/unpassenden Index verwendet und wir dann (um Multi-DB-Support zu haben) extra für Oracle die Query etwas anders zusammenbauen müssen damit es nicht Grotten-Langsam wird.

[H4ndy]

Zitat:

Zitat von alzaimar

a.k.a. Cache.

Viele stellen den Cache aus (zumindest schreibend), um bei einem Absturz keine Daten zu verlieren (sprich jede Aenderung wird sofort auf die Platte geschrieben).

Aber "wenig auf Festplatte machen" heisst ja auch nicht automatisch nur nen Cache zu nuzten, sondern auch die Algorithmen so zu verbessern, dass die nur ein Minimum in den Dateien "rumsuchen" muessen (eben Indizies, etc.).

@Bernhard Geyer: Wow, das nenn ich mal Inside-Infos. Haette nicht gedacht, dass eine Enterprise-Loesung solche Probleme hat.

[Bernhard Geyer]

Zitat:

Zitat von H4ndy

@Bernhard Geyer: Wow, das nenn ich mal Inside-Infos. Haette nicht gedacht, dass eine Enterprise-Loesung solche Probleme hat.

Wir haben 3 der 4 meist verwendeten DBs (Oracle, MS SQL Server, MySQL) beim Kunden im Einsatz. Und wenn wo Probleme auftauchen dann ist es sehr oft Oracle (und es ist nicht so das Oracle die größten Installationen wären). Oracle ist auch in unserer Test-Umgebung am empfindlichsten. Ab und zu zerschießt sich Oracle selbst und dann heist es: Altes Image reaktivieren.

[s.h.a.r.k]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von H4ndy

@Bernhard Geyer: Wow, das nenn ich mal Inside-Infos. Haette nicht gedacht, dass eine Enterprise-Loesung solche Probleme hat.

Wir haben 3 der 4 meist verwendeten DBs (Oracle, MS SQL Server, MySQL) beim Kunden im Einsatz. Und wenn wo Probleme auftauchen dann ist es sehr oft Oracle (und es ist nicht so das Oracle die größten Installationen wären). Oracle ist auch in unserer Test-Umgebung am empfindlichsten. Ab und zu zerschießt sich Oracle selbst und dann heist es: Altes Image reaktivieren.

Um welche Version handelt es sich denn? War gerade über den Post echt überrarscht, weil Oracle wohl sehr viel Marktanteil hat und sich sowas doch eigentlich kaum Leistung dürfte :gruebel: soll aber nicht heißen, dass ich dir nicht glaube.

[alzaimar]

Zitat:

Zitat von H4ndy

Zitat:

Zitat von alzaimar

a.k.a. Cache.

Viele stellen den Cache aus (zumindest schreibend), um bei einem Absturz keine Daten zu verlieren (sprich jede Aenderung wird sofort auf die Platte geschrieben).

Ein Programm mit Schreibcache ist niemals eine Daten*bank*, denn per se sollen die Daten in einer Datenbank *sicher* aufgehoben werden. Ergo sind atomare Schreiboperationen oft erschreckend langsam, weswegen es z.B. bulk inserts gibt.

Eine Datenbank ohne Lesecache ist in etwa so schnell wie etwas Selbstgefrickeltes. Unterschiede machen sich dann nur in der Verwendung undokumentierte API-Routinen (MSSQL, Scatter/Gather-IO) oder der Reservierung von Resourcen (Oracle, eigene Beobachtungen) bemerkbar. Wie Matze schon eingangs erwähnte, kann eine DB ohne Lesecache (oder direkt nach einem Neustart) nicht sonderlich schnell sein, denn Daten müssen über das Bottleneck File-IO erstmal gelesen werden.

Mittlerweile sind sich die meisten DBMS hinsichtlich ihrer in-Memory Performance relativ ähnlich, nur wenn es richtig viele Daten sind, trennen sich Spreu von Weizen.

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von alzaimar

Zitat:

Zitat von H4ndy

Dazu kommt noch geschicktes Parsen

eher nicht, unbedeutend.

Es ist bedeutent, wenn sich der Query Analyser "verrennt". Wir haben die Erfahrung damit das dies des öfteren bei Oracle passiert das dieser den falschen/unpassenden Index verwendet..

Das liegt aber nicht am Parser, sondern am Analyser/Optimiser/. Ich dachte, bei Oracle muss man die Query quasi per Hand (oder mit Hilfe eines Tools) umformatieren. Aber auch MSSQL liefert oft erschreckend schlechte Optimierungen...

Ich glaube wir sind uns hier im Grunde einig, nur der Terminus "Parser" hat mir nicht gepasst, denn der ist ja ziemlich doof und erzeugt nur einen Syntaxbaum. Und das ist garantiert kein Bottleneck.

[jaenicke]

Zitat:

Zitat von Matze

im Endeffekt sind Datenbanken doch nichts anderes als Dateien, die auf Festplatten liegen. Dennoch sind Datenbanken deutlich schneller, als wenn Schreib- und Lesezugriffe manuell über Dateizugriffe erfolgen würden.

Wobei es da auch massive Unterschiede gibt. Natürlich haben Datenbanken bei sehr großen Datenmengen noch mehr Vorteile, aber oft sind Geschwindigkeitsprobleme bei Eigenentwicklungen auch schlicht auf schlechte Optimierung zurückzuführen.

Mit MMFs und einer cleveren Dateistruktur kann man auch ohne echte Datenbanken eine gute Geschwindigkeit hinbekommen. Das lohnt sich für größere Datenmengen einfach kaum um Vergleich zu DBs, da der Aufwand viel zu groß wird, aber eine JIT-Filterung direkt bei der Eingabe in ein Edit habe ich auch bei mehreren tausend Datensätzen in unter 10 Millisekunden hinbekommen inklusive Anzeige als Tabelle und inkl. Farbhighlighting.

Das sind natürlich ganz andere Datenmengen als bei professioneller Verwendung von DBs auftreten, so dass man da noch ganz andere Probleme bekäme, wenn man das selbst machen wollte. Aber gerade bei kleinen Hobbytools sehe ich schon öfter, dass einfach nicht gut optimiert wird und dadurch dann die Geschwindigkeit so schlecht ist. Denn bei kleineren Datenmengen sind echte DBs nicht unbedingt schneller als eine gut optimierte Eigenlösung. (Aber einfacher. :mrgreen:)

Und was den Dateizugriff an sich angeht:
Mit meinem Registryeditor lese ich zeichenweise die INI-artigen Registrydateien ein. Inklusive Einlesen und Anzeige komme ich da etwa auf die halbe Maximalgeschwindigkeit der Festplatte, bei mir z.B. mit SSD auf 90 MiB/s, so dass z.B. eine 350 MiB Datei in 5 Sekunden komplett analysiert und angezeigt ist, mit einer echten Festplatte in ca. 9-15 Sekunden (je nach Rechner). ;-)

[Bernhard Geyer]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1025747)

Um welche Version handelt es sich denn? War gerade über den Post echt überrarscht, weil Oracle wohl sehr viel Marktanteil hat und sich sowas doch eigentlich kaum Leistung dürfte :gruebel: soll aber nicht heißen, dass ich dir nicht glaube.

Entweder war's ne 8er oder 9er. Bei einem Kunden hatte sich das Probel eh aufgelöst da er auf ne 10/11er gewechselt ist.

[mkinzler]

Ist es also bei Oracle auch so wie bei EB/CG, dass Fehler nur in neueren Versionen behoben werden

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1025795)

Ist es also bei Oracle auch so wie bei EB/CG, dass Fehler nur in neueren Versionen behoben werden

Bei Oracle ist eher die Frage ob auch alle Updates/Patches eingespielt sind. Oft werden einmal laufenden Oracle-Instanzen möglichst nicht mehr angelangt um nichts kaputt zu machen. Und wenn aktualisiert dann wird gleich der Rundumschlag (Neue HW, neues OS, neue Oracle-Version) durchgeführt um die nötigen Migrationsaufwände minimal zu halten (bei einem ERP/PLM wäre es nicht so gut wenn die DB mal 1-2 Tage ausfallen würde).