Anbei ein Link zum Thema MySQL & Document Store: ORDIX News

Hier ist eine wichtige Zahl:

Ein Coredump von einem MySQL auf einer Maschine mit knapp unter 200G Speicher dauert 15 Minuten. Auf SSD. Auf eine Festplatte dauert der gleiche Coredump dann knapp über 30 Minuten.

Warum ist das eine wichtige Zahl?

SSD sind schnell. Linear schreiben sie mehr als 200 MB pro Sekunde weg - ein ziemlich beeindruckendes Tempo, und noch dazu in einer Disziplin, wo sie nicht einmal optimal nutzbar sind. Auch moderne Serverfestplatten sind schnell - beim linearen Schreiben immerhin knapp halb so schnell wie eine SSD, oder 100 MB pro Spindel linear.

Aber moderne Maschinen haben halt auch eine sehr große Menge Speicher. Und 200 GB bei 200MB pro Sekunde sind halt dann eine Viertelstunde pro Full Dump oder Full Scan.

In Eine reiche NoSQL-Anfragesprache macht Ulf Wendel sich …

Ich brauche einmal Hilfe. Von Euch. Ich verstehe nämlich ein Konzept nicht. Es geht um den Begriff "Schemaless", der im Zusammenhang mit einigen NoSQL-Datenbanken verwendet wird.

Ich kann verstehen, daß für einige Leute ein ALTER TABLE wie in MySQL ein Problem ist, weil es Tabellen während der Schemaänderung lockt. Da ALTER TABLE in vielen Fällen die Daten zur Durchführung der Änderung umkopieren muß, kann dieses Lock entsprechend lange bestehen bleiben, wenn die Daten nur hinreichend groß sind.

Ich kann nicht verstehen, wieso Leute glauben, daß "Schemaless" da eine Hilfe wäre oder wieso Leute glauben, daß es so etwas wie "Schemaless" überhaupt gibt.

Daten in Datenbanken existieren ja in der Regel nicht im luftleeren Raum, sondern sie werden von Code genutzt. Dieser Code macht Annahmen über die Attribute, die in einer Tabelle (oder was immer Euer NoSQL als Tabellenäquivalent verwendet) existieren …

Beim Durchstöbern der verschiedenen NoSQL-Datenspeicher stellt sich mir die Frage, wieso man das alles überhaupt will. Genauer: Was genau ist das Problem, das man mit NoSQL lösen möchte?

Diejenigen Leute, die NoSQL-Lösungen einsetzen, haben in der Regel die Schwierigkeit, daß ihre Datenmenge größer wird, als man auf einer einzelnen Maschine mit der geforderten Servicequalität handhaben kann.

Im Webbereich sind die Anforderungen für interaktives Browsen oft so, daß man die gewünschten Antwortzeiten nur dann erreichen kann, wenn die dabei verwendeten Datenbanken ihre Daten und Indices zum allergrößten Teil im RAM halten können. Verfügbarkeit und Preis von Speicher sind aber Grenzen gesetzt - mit aktuellen Nehalem-Kisten zum Beispiel liegt der Sweet-Spot irgendwo bei 48G oder 96G Hauptspeicher, die Datenbankgröße für solche zeitkritischen Systeme also nach meinen Erfahrungen zwischen 100G und 200G.

Erst …

Oli (from Dual): Ich denke, daß nur ca. 1 Promille der DB User so Zeugs wirklich braucht... aber heiß sind alle drauf. Die sollten besser mal SQL Tuning und Indexing lernen, statt mit so Zeugs rumzuspielen. Basics nicht im Griff, aber dann mit dem hochcomplexen Ding spielen. :)

• Ronald Bradford experimentiert mit MongoDB, einem Key-Value Store.
• Mehr MongoDB und Distributed Consistency.
• Mehr Distributed Consistency, sehr schöne Kurzerklärung. Schnabeltiere rocken.
• HBase vs. …