Suche Empfehlung: Key-Value DB [solved]

Message

Post by **slick** » Thu Mar 24, 2011 9:06 am

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 · Post by **manuels** » Thu Mar 24, 2011 9:51 am

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 · Post by **Necoro** » Thu Mar 24, 2011 10:10 am

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 · Post by **Knieper** » Thu Mar 24, 2011 6:51 pm

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 · Post by **Necoro** » Thu Mar 24, 2011 7:07 pm

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.

l3u · Post by **l3u** » Fri Mar 25, 2011 6:03 pm

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 · Post by **Knieper** » Fri Mar 25, 2011 6:48 pm

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...

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 · Post by **l3u** » Mon Mar 28, 2011 9:56 am

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 · Post by **Knieper** » Mon Mar 28, 2011 10:18 am

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

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.

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.

Post by **slick** » Mon Mar 28, 2011 11:42 am

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 · Post by **l3u** » Mon Mar 28, 2011 5:55 pm

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 · Post by **manuels** » Tue Mar 29, 2011 11:07 am

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?

Post by **slick** » Tue Mar 29, 2011 1:37 pm

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 ...

Post by **slick** » Thu Apr 07, 2011 7:26 pm

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 · Post by **manuels** » Fri Apr 08, 2011 10:34 am

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

Post by **slick** » Fri Apr 08, 2011 11:05 am

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 · Post by **Knieper** » Fri Apr 08, 2011 11:53 am

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.