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.