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.