Was macht Datenbanken so schnell?

[s.h.a.r.k]

Zitat von Bernhard Geyer:

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 soll aber nicht heißen, dass ich dir nicht glaube.

[alzaimar]

Zitat von H4ndy:

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 von Bernhard Geyer:

Zitat von alzaimar:

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

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 von s.h.a.r.k:

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 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 von mkinzler:

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