Suche Empfehlung: Key-Value DB [solved]

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

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?

manuels · Advocate Joined: 22 Nov 2003 Posts: 2146 Location: Europe

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)
_________________
Build your own live cd with catalyst 2.0!

Necoro · Veteran Joined: 18 Dec 2005 Posts: 1912 Location: Germany

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.
_________________
Inter Deum Et Diabolum Semper Musica Est.

Knieper · l33t Joined: 10 Nov 2005 Posts: 846

Necoro · Veteran Joined: 18 Dec 2005 Posts: 1912 Location: Germany

Da ich nur GDBM, NDBM und BDB im Kopf hatte, hatte ich deinem Benchmark zufolge sogar recht

. Die ganzen anderen kannte ich schlicht nicht, hab mit dem Thema auch nix weiter zu tun.
_________________
Inter Deum Et Diabolum Semper Musica Est.

l3u · Posted: Fri Mar 25, 2011 6:03 pm Post subject:

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 · l33t Joined: 10 Nov 2005 Posts: 846

l3u · Posted: Mon Mar 28, 2011 9:56 am Post subject:

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 · l33t Joined: 10 Nov 2005 Posts: 846

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

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 · Posted: Mon Mar 28, 2011 5:55 pm Post subject:

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 · Advocate Joined: 22 Nov 2003 Posts: 2146 Location: Europe

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

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 · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

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 · Advocate Joined: 22 Nov 2003 Posts: 2146 Location: Europe

Allerdings! Bekommt jedes Objekt in der DB auch noch eine Standard-ID zugewiesen, oder setzt du die ID mittels einer deiner drei Daten?
_________________
Build your own live cd with catalyst 2.0!

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

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 · l33t Joined: 10 Nov 2005 Posts: 846

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.
_________________
Je dümmer desto Gnome/KDE.