# Suche Empfehlung: Key-Value DB [solved]

## slick

Suche eine Empfehlung für eine Key-Value DB für ca. 5-50 Mio. Datensätze. Key ist md5 und Value ein String (max. ~100 Zeichen). Normale Operationen sind Werte eintragen und anhand Key lesen. Eine Suche in den Values wird nicht benötigt, optional wäre aber die Ermittlung des Key anhand Value von Vorteil. 

Einfaches Handling und weniger Ressourcenverbrauch ist wichtiger als Geschwindigkeit.

Zugriff soll lokal über Console-Tools wie auch optional remote über eine API für andere Programiersprachen (REST/HTTP) erfolgen. 

Etwas SQL basiertes scheint mir dafür völlig fehl am Platz, für den Rest fehlt mir aber die Erfahrung. Wer kann mir was empfehlen?

//EDIT

Ich liebäugel da ein wenig mit CouchDB. Wollte ich sowieso mal ausprobieren, dementsprechend wäre das o.g. Szenario doch optimal zum Testen. Oder wäre CouchDB da völlig fehl am Platz, weil es doch dokumentorientiert ist?Last edited by slick on Mon Mar 28, 2011 11:42 am; edited 1 time in total

----------

## manuels

CouchDB wäre wohl nicht fehl am Platze, aber ich hab mir auch mal verschiedene NoSQL-DBs angeschaut.

Irgendwie bin ich mit CouchDB nicht wirklich warm geworden. Ich präferiere MongoDB, kann es dir aber nur damit begründen, dass ich das Konzept von CouchDB etwas zu kompliziert finde.

MongoDB ist da weitaus einfacher zu verstehen (vielleicht, weil es auch nicht soviele Features hat, wie z.B. das Outputformat als Javascript-Programm in der Datenbank zu spezifizieren. Ich finde, dass sowas nicht die DB, sondern das Programm machen sollte)

----------

## Necoro

Als Alternative zu den Server-Varianten gibt es auch die auf einem System bereits installierten *dbm-Varianten, bzw als wohl effizienteste Variante die Oracle Berkeley DB (sys-libs/db). Diese bieten zwar kein Cmdline-Tools an sich an, aber mit den Perl/Python/etc Bindings sollten sich Wrapper-Skripte bei Bedarf schnell bauen lassen.

Wie die sich jetzt in Bezug auf Performance zu zB MongoDB verhalten, weiß ich aber nicht.

----------

## Knieper

 *Necoro wrote:*   

> bzw als wohl effizienteste Variante die Oracle Berkeley DB (sys-libs/db

 

Wie kommst Du darauf?

Benchmark Test of DBM Brothers

Benchmarking BDB, CDB and Tokyo Cabinet on large datasets

bdb kenne ich von früher als ziemlich instabil, cdb ist nett - allerdings beim Schreiben unhandlich. Ich hätte Tokyo Cabinet empfohlen, aber inzwischen gibt es einen Nachfolger: http://1978th.net/kyotocabinet/

----------

## Necoro

Da ich nur GDBM, NDBM und BDB im Kopf hatte, hatte ich deinem Benchmark zufolge sogar recht  :Smile: . Die ganzen anderen kannte ich schlicht nicht, hab mit dem Thema auch nix weiter zu tun.

----------

## l3u

Für Schlüssel -> Wert würd ich Berkeley DB nehmen. Hat null Overhead, weil sie genau das und NUR das macht (und kann): den Wert für einen Schlüssel liefern. Ohne Beweise liefern zu können bin ich der Meinung, daß das die schnellste, schlankeste und adäquateste Lösung in dem Fall ist. In b8 funktioniert sie jedenfall super für genau den selben Einsatzzweck. Inwiefern es schnellere und bessere Datenbanken gibt, die genau das selbe machen, weiß ich nicht.

----------

## Knieper

 *l3u wrote:*   

> Ohne Beweise liefern zu können bin ich der Meinung, daß das die schnellste, schlankeste und adäquateste Lösung in dem Fall ist.

 

Wer sich so aus dem Fenster lehnt...

 *Quote:*   

> Inwiefern es schnellere und bessere Datenbanken gibt, die genau das selbe machen, weiß ich nicht.

 

muss einfach fallen.

Edit: Falls Du Transaktion etc. brauchst. InnoDB usw. kann man auch ohne SQL einsetzen.

----------

## l3u

Ich sag ja nur, mit was ich gute Erfahrungen gemacht habe … ohne Anspruch auf Richtigkeit und/oder Allwissen. Außerdem bitte ich auch Necoro anzustänkern, der hat auch „Berkeley DB“ gesagt :-P

----------

## Knieper

 *l3u wrote:*   

> Ich sag ja nur, mit was ich gute Erfahrungen gemacht habe … ohne Anspruch auf Richtigkeit und/oder Allwissen

 

 *Quote:*   

> daß das die schnellste, schlankeste und adäquateste Lösung in dem Fall ist

 

Und Du bist nicht in der Lage die verlinkten Benchmarks zu überfliegen, um einzusehen, dass BDB weder die schnellste, noch die schlankeste Lösung ist? Ob sie adäquat ist, kann man schlecht beurteilen, dazu hat slick viel zu wenig Randbedingungen angegeben.

 *Quote:*   

> Außerdem bitte ich auch Necoro anzustänkern, der hat auch „Berkeley DB“ gesagt 

 

Kann er ja auch sagen. Er ist aber in der Lage zu lesen und kennt jetzt mögliche Alternativen.  :Twisted Evil: 

----------

## slick

Ich habe mich jetzt für MongoDB entscheiden. Ist vermutlich für den gedachten Einsatzzweck allein deutlich overkill, allerdings wollte ich das sowieso mal testen und auch vlt. anderes damit ausprobieren. Dank euch. Solved

Dürft natürlich gern noch weiter diskutieren...

----------

## l3u

Nein, jetzt bin ich beleidigt :-P Spaß beiseite, ist ja nett, wenn man was Neues lernt. Und Tokyo Cabinet kannte ich tatsächlich nicht. Werd ich mir mal bei Gelegenheit anschauen.

----------

## manuels

 *slick wrote:*   

> Ich habe mich jetzt für MongoDB entscheiden. Ist vermutlich für den gedachten Einsatzzweck allein deutlich overkill, allerdings wollte ich das sowieso mal testen und auch vlt. anderes damit ausprobieren. Dank euch. Solved

 Wieviele key->value pairs hast du denn jetzt drin?

Kannst du mal schauen, wie lang das auffinden eines Keys benötigt?

----------

## slick

Wird noch was dauern bis ich da Zahlen liefern kann. Bin gerade erst dabei das Gedachte umzusetzen und wird wohl noch was brauchen. Leide momentan unter chronischem Freizeitmangel. (Habe nur tagsüber @Work die Zeit mir darüber Gedanken zu machen bzw. mich zu belesen)

Wenn dann wäre das auch nur virtualisiert, allerdings ist die mysql auch virtualisiert und da stecken die Daten auch noch drin, d.h. ich könnte die beiden mehr oder minder direkt vergleichen. So viel Spielspaß ... so wenig Zeit ...

----------

## slick

Also ich habe zwar noch keine Zahlen in Bezug auf die Geschwindigkeit, allerdings ist der Speicherverbrauch von MongoDB echt heftig.

Ich habe eine Textdatei eingelesen, je Zeile 3 String Werte zu je 3-40 Zeichen, insgesamt ca. 6,1. Mio. Datensätze (je eine Zeile in der Mysql Tabelle, entspricht je ein Dokument in MongoDB). Ok, keine reine Key-Value, aber immerhin sehr einfach strukturierte Daten.

Gesamt-Speicherverbrauch auf der Platte (gleiches Dateisystem)

- als reine Textdatei: 295 MB

- als Mysql (MyIsam) incl. 2 Index: 496 MB 

- als MongoDB incl. 2 Index: 5,7 GB

Heftig ... hätte ich nicht erwartet.

----------

## manuels

Allerdings! Bekommt jedes Objekt in der DB auch noch eine Standard-ID zugewiesen, oder setzt du die ID mittels einer deiner drei Daten?

----------

## slick

Hatte es erstmal bei der zusätzlichen Standard-Id belassen.

Ich habe so gut es ging Standard-Werte verwendet ohne mich vorher tiefer damit zu befassen. Das hat z.B. auch die Auswirkung das alle eingetragenen Werte case-sensitiv sind. Sowohl Werte selbst als auch der Index. (Eine Howto zu case-insensitiven Werten empfahl die Werte doppelt im Dokument abzuspeichern. Einmal case-sensitiv und einmal z.B. in Kleinbuchstaben.) Das macht auch aus Sicht der Suche wieder Sinn, denn eine normale Suche nach Werte ist case-sensitive. Eine case-insensitive Suche ist zwar mittels Expressions möglich, aber da merkt man schon beim einfachen Ausprobieren auf der Console einen deutlichen Performance-Unterschied. 

Nichts destotrotz sehe ich die NoSql DBs als interessanten Ansatz mit durchaus Existensberechtigung.

----------

## Knieper

Es gibt doch genug String Metriken und (perceptual) Hashfunktionen, die case(in)sensitiv sind - Du wirst doch nicht alle Werte auf einen Match hin durchsuchen?! Wenn es um Text allg. geht, fährst Du mit Lucene etc. besser.

----------

