Verwendungsmöglichkeiten von Key-Value Datenbanken

[metty]

Hallo zusammen,

über NoSQL Ansätze wird aktuell mehr oder weniger häufig diskutiert. Die einen sehen es als DAS Neue "Ding", andere sind bei dem Thema nicht ganz so enthusiastisch.
Sieht man sich die nackten Zahlen von Key-Value Stores wie z.B. Redis an (ca. 110000 SETs/second, 81000 GETs/second auf einer Low-End Linux Kiste) ist es verständlich warum die eine Gruppe davon so begeistert ist. Würde man solche Key-Value Stores für stark frequentierte Websites nutzen, könnte man mit kleinerem Hardware-/Konfigurationsaufwand ziemlich hohe Durchsätze erreichen. Leider ist nicht alles immer so schön wie es scheint, denn so schnell werden sich SQL-Datenbanken nicht ablösen lassen. In manchen Szenarien wird dies wohl nie der Fall sein.

Aber wofür lassen sich solche Key-Value Stores in einem produktiven (Website) Setup wirklich nutzen? Da Redis persistente Speicherung ermöglicht, würde ich es für Dinge nutzen wie:

• Zugriffszähler von Dateien/Seiten
• Cache für Daten, die aus einer Datebank kommen, sich aber eigentlich so gut wie nie ändern
• Um Daten zu ordnen/sortieren
• ...

Habt ihr solche Key-Value Stores im Einsatz und für was verwendet ihr sie?
Was wären weitere Einsatzszenarien dafür um im Punkto Geschwindigkeit (z.B. einer Website) zu profitieren?

Vielen Dank fürs lesen

Freundliche Grüße

[Hyperion]

Ich bin grad dabei einen minimalistischen Stackoverflow-Clone mit bottle zu schreiben. Als Datenbackend setze ich da auf mongodb; vor allem um einmal in die Welt der Key-Value Datenbanken einzutauchen und ein Gefühl für Einsatzmöglichkeiten und das Handling zu bekommen.

Viel kann ich Dir deswegen dazu noch nicht sagen; aber speziell für die klassischen 1:n-Relationen ist der KV-Ansatz ziemlich cool, da Du die "n"-Seite wunderbar einbetten kannst.

Zudem bist Du von der Datenstruktur felxibler. Du musst Dich eben nicht wirklich zur Designtime festlegen, welche Attribute Du verwalten möchtest, sondern diese können komplett unterschiedlich von Eintrag zu Eintrag sein.

Ich habe das grad bei der Erstellung einer Übungsaufgabe für ein Klausurrepititorium erlebt: Im Lego-Umfeld (LDraw) haben die unterschiedlichen Lego-"Steine" komplett unterschiedliche Attribute. Bei manchen sind es Länge, Höhe und Breite; andere haben "Löcher" usw. In einem relationalen Ansatz kannst Du das als Matrix in einer Tabelle darstellen und die nicht vorhandenen Attribute bleiben "leer", oder aber Du erstellst n-Relationen zu n-Tabellen, die dann speziell für eine Gruppe von Eigenschaften zuständig ist. Beides irgend wie komplizierter als die "freie" Wahl zu haben für Eigenschaften.

Wo ich so darüber philosophiere sollte ich wirklich mal an einem Konverter für die LDraw Elemente in eine KV-DB schreiben

[metty]

Viel kann ich Dir deswegen dazu noch nicht sagen; aber speziell für die klassischen 1:n-Relationen ist der KV-Ansatz ziemlich cool, da Du die "n"-Seite wunderbar einbetten kannst.

Stimmt, auf das bin ich auch gekommen.
Ich betreue eine Bildergalerie eines Kumpels und hier wäre das natürlich eine coole Verwendungsmöglichkeit.

In Redis "gesprochen":

Code: Alles auswählen

r.get('album1')

und schon schon hat man die ganzen Bilder. Das geht natürlich auch mit SQL...

Ich denke, das sich solche Key-Value Stores, die viel performanter ans Werk gehen wie SQL-Datenbanken, aktuell nur für stark frequentierte Seiten relevant (bzw. wirklich nützlich) sind. Denn wenn 5x am Tag in irgendeinem Blog ein Kommentar geschrieben wird, dann verkraftet das auch MySQL/PostgreSQL usw.

Denkt man aber z.B. an Facebook und Co. wo z.B. ein Zähler ala "Deine Profilseite wurde xxxx mal aufgerufen" mitläuft, da wären das schon seeehr viele Schreibaktionen auf einmal. Klar, das kann man mit einer gescheiten Entwicklung umgehen, aber das kostet mehr Entwicklungsarbeit als eine INCR('xy') Aktion eines Key-Value Stores.

Ich persönlich finde Mongo DB schon sehr interessant.
Muss ich mich auch mal damit einarbeiten.

Twitter selbst setzt (scheinbar) mittlerweile auf Key-Value Stores wie Cassandra.
http://www.computerworld.com/s/article/ ... L_database

[Panke]

Kennt jemand ein paar gute Artikel zum Thema, bspw. von CACM?

Warum genau sind die KV schneller als die Relationen?

[metty]

Warum genau sind die KV schneller als die Relationen?

Hier wurde was auf stackoverflow geschrieben:
http://stackoverflow.com/questions/2354 ... tional-dbs

Wie in dem Thread von stackoverflow geschrieben wurde, entfallen bei Key-Value Stores Joins, Locking usw.

So weit ich weiß verzichtet Facebook so weit es geht auf Joins bei ihren SQL-Abragen, um mehr Performance aus ihren MySQL Datenbanken zu "quetschen". Das ist zwar nicht ganz im Sinne des Erfinders (der Normalisierung), zeigt aber das so (ultra)große Websites (wenn man die Zahl der Transaktionen als Maß nimmt) wie Facebook, Twitter usw. gut überlegen mussten und immer noch müssen, um das mit "normalen" SQL-Datenbanken zu schaffen. Denn ich glaube kaum das die Zahl der Nutzer weniger wird, ganz im Gegenteil.

Wenn man sich die Zahlen von Twitter "auf der Zunge zergehen lässt", z.B. unter http://popacular.com/gigatweet/ oder http://www.tweespeed.com/ (wenn die Zahlen stimmen), ist das einfach nur krass was die Maschinen/Konfiguration wegstecken müssen. Jeder tweet ist ja im Endeffekt eine Schreib-Transaktion auf die Datenbank.

[BlackJack]

Hier ist vielleicht der Pycon-Beitrag To relate or not to relate, that is the question (#99) von Mark Ramm interessant. Da geht's unter anderem um SourceForge und deren Entscheidung für MongoDB.

[Gabelmensch]

Das ist im Grunde doch irgendwie das Dictionary Prinzip von Python oder?

[BlackJack]

@Gabelmensch: Jain. Reine Key-Value-Stores schon, allerdings geht's hier ja auch um NoSQL im allgemeinen. MongoDB ist kein KV-Store, weil man über deutlich mehr als über den Key an die Daten rankommt.

[noisefloor]

Hallo,

ich nutzte ab und an CouchDB. Gut, dass ist eine dokumentenorientierte Datenbank eine kein plattes KV-Store.

Ich benutzte CouchDB bei uns in der Firma im Intranet, um tech. Datenblätter generieren zu lassen.

Drei Gründen, warum CouchDB:

1. Ich brauche mir über die Feldlängen keine Gedanken zu machen.
2. Ich habe nur das in der DB, was ich brauche - und keine (SQL) NULL Werte. Manche Daten gibt's nämlich nur auf Englisch, manche auf DE + EN usw.
3. Mit Pythpn und dem python-couchdb Modul kann man so schön einfach aus die Daten aus der DB zu greifen.

Das geht sicherlich auch alles mit MySQL und Co, aber es ist IMHO so einfacher.

Grundsätzlich wird ich objektorientierte DB empfehlen, wenn man viel Text mit vorher nicht definierter Länge speichern muss (möchte) - also Blog, Forum etc.

Gruß, noisefloor