Warum immer Ruby on Rails?

[Darii]

@Darii & @ajohannes: Bei Relationen kommt es ja aber auf die Kardinalität an! Eigentlich brauchst Du nur bei n:m-Relationen so etwas wie ein relationales Konzept. Alles andere kannst Du ja direkt ineinander schachteln (wie man es bei XML / JSON ja auch intuitiv macht). Insofern sind Projekte ohne n:m (oder mit nur wenigen) durchaus für "NoSQL" geeignet.

Wie gesagt, mir fallen da kaum Daten für die diese Key-Value-Datenbanken irgendwie zu gebrauchen wären. Das einzige was ich interessant finde ist MogoDBs GridFS.

Ich werden denn Eindruck nicht los, dass diese Key-Value-Datenbanken die Nachteile von Objektdatenbanken und relationalen Datenbanken kombinieren, ohne neben der (dann mehr oder weniger trivialen) Skalierbarkeit wirkliche Vorteile zu bieten.

[Hyperion]

@Darii & @ajohannes: Bei Relationen kommt es ja aber auf die Kardinalität an! Eigentlich brauchst Du nur bei n:m-Relationen so etwas wie ein relationales Konzept. Alles andere kannst Du ja direkt ineinander schachteln (wie man es bei XML / JSON ja auch intuitiv macht). Insofern sind Projekte ohne n:m (oder mit nur wenigen) durchaus für "NoSQL" geeignet.

Wie gesagt, mir fallen da kaum Daten für die diese Key-Value-Datenbanken irgendwie zu gebrauchen wären. Das einzige was ich interessant finde ist MogoDBs GridFS.

Ich werden denn Eindruck nicht los, dass diese Key-Value-Datenbanken die Nachteile von Objektdatenbanken und relationalen Datenbanken kombinieren, ohne neben der (dann mehr oder weniger trivialen) Skalierbarkeit wirkliche Vorteile zu bieten.

Mir fällt da spontan ein Adressbuch ein. Da sehe ich auf Anhieb ganz viele 1:n-Relationen... das dürfte mit MongoDB wesentlich einfacher zu realisieren sein, als mit einem ORM.

Ist nicht sourceforge auch auf eine KV-DB umgestiegen? Iirc gabs da nen Vortrag auf der PyCon...

[Darii]

Mir fällt da spontan ein Adressbuch ein. Da sehe ich auf Anhieb ganz viele 1:n-Relationen... das dürfte mit MongoDB wesentlich einfacher zu realisieren sein, als mit einem ORM.

Klar -> Gridfs. Für alles was ich auch ebenso gut in eine Datei schreiben könnte ist MongoDB super geeignet.

[Hyperion]

Mir fällt da spontan ein Adressbuch ein. Da sehe ich auf Anhieb ganz viele 1:n-Relationen... das dürfte mit MongoDB wesentlich einfacher zu realisieren sein, als mit einem ORM.

Klar -> Gridfs. Für alles was ich auch ebenso gut in eine Datei schreiben könnte ist MongoDB super geeignet.

Ich glaube wie reden aneinander vorbei...

[BlackJack]

@Darii: MongoDB bietet dann doch ein paar mehr Möglichkeiten die Daten abzufragen als Dateien. Oder Indexe zu erstellen.

[Darii]

Ich glaube wie reden aneinander vorbei...

Nein tun wir nicht. Den Vorteil den Mongo-DB an dieser Stelle bietet ist, dass man das ganze mit wenig Aufwand indizieren kann, wenn man die Adressbucheinträge entsprechend strukturiert abspeichert.

MongoDB ist eine Dokumenten-DB, für alles was man normalerweise als Dokument in Dateisystem schreiben würde ist Mongo-DB super geeignet. Wobei man da vermutlich Probleme mit steigender Komplexität kriegen würde. Ein Word-artiges-Dokument würde ich nicht unbedingt als JSON serialisiert in MongoDB ablegen wollen.

[metty]

Wie gesagt, mir fallen da kaum Daten für die diese Key-Value-Datenbanken irgendwie zu gebrauchen wären.

Key-Value Stores sind in meinen Augen auch keine "wirkliche" Alternative für ein RDBMS. Da sind dokumentenbasierte Ansätze ala MongoDB oder CouchDB sicher besser zu geeignet.

Mir fallen für Key-Value Stores schon einige Einsatzgebiete ein, wenn auch nicht für die hauptsächliche Speicherung von z.B. Benutzerdaten etc. Aber am Beispiel von Redis, das mehrere 10.000 SETs/GETs pro Sekunde ausführen kann, lassen sich solche Stores für Dinge wie Berechnungen, bzw. einfach alles wo viele Schreib-/Leseanfragen auftreten verwenden.

[sma]

Mal davon abgesehen, dass ein System wie MongoDB im Projekt möglicherweise einfacher und flexibler zu benutzen ist als z.B. mysql, beginnen NoSQL-DBs ihre Vorteile erst richtig auszuspielen, wenn es um Performance und horizontale Skalierbarkeit geht.

Wenn Twitter 300 GB Logdateien pro Stunde (80 MB pro Sekunde, 2628 TB im Jahr) speichern können muss, ist da eine relationale (SQL) DB schnell überfordert - gerade wenn man überlegt, dass parallel daraus auch noch gelesen werden soll und die Leseoperationen sicherlich noch umfangreicher sind.

Mir reicht aber eigentlich schon das Argument der Einfachheit. Im meinem aktuellen Projekt wollen wir schnell zählen und Oracle (das wir nicht schnell genug zu machen in der Lage sind) müsste dies machen:

Code: Alles auswählen

while True:
  rs = query("select c0 from counters where id=:name for update")
  if rs.next():
    v = int(rs.get("c0")) + delta
    if update("update counters set c0 = :v where id=:name") == 1:
      break
  else:
    if update("insert into counters (id, c0) values (:name, :delta)") == 1:
      break

Bei mysql oder sqlite könnte man "insert or replace" als Befehl benutzen, aber ich befürchte, bei Oracle könnte nur eine stored procedure die Sache einfacher machen. Hinzu zu meinen Pseudocode kommt noch, dass wir Vector-Counter haben, also c0, ... cN existiert und dadurch die SQL-Anweisungen eigentlich noch mehre Spalten haben.

Zum Vergleich MongoDB:

Code: Alles auswählen

update({_id:name}, {$inc: {c0: delta}}, true)

Oder Redis:

Code: Alles auswählen

hincr(name, "c0", delta)

Stefan