BT

Moneta: An Interface to Key-Value Stores like Tokyo Cabinet, Memcache

| by Mirko Stocker Follow 1 Followers on Feb 24, 2009. Estimated reading time: 1 minute |

Relational databases are only one option when it comes to storing your data. Depending on the actual case, it might be worth taking a look at a key-value store. If the data is stored and accessed mainly by a primary key, a key-value store might be a better option than the relational model. So, what are key-value stores? The name sounds awfully similar to the plain-old hash, and conceptually, it's just that.

Compared to a fully fledged RDBMS, key-value stores are much simpler, which is likely also the reason why there are so many competing implementations available. We take a look at Tokyo Cabinet and Moneta, a unified interface for different key-value stores.

Tokyo Cabinet is a C library that implements a very fast and space efficient key-value store:

The database is a simple data file containing records, each is a pair of a key and a value. Every key and value is serial bytes with variable length. Both binary data and character string can be used as a key and a value. There is neither concept of data tables nor data types. Records are organized in hash table, B+ tree, or fixed-length array.

Besides bindings for Ruby, there are also APIs for Perl, Java, and Lua available.

To share Tokyo Cabinet across machines, Tokyo Tyrant provides a server for concurrent and remote connections. For some examples and more information on Tokyo Cabinet, you might want to take a look at Ilya Grigorik's introductory article.

Suppose you have decided to use a key-value store, but don't want to decide on a specific implementation yet, Moneta might come in handy. It "aims to provide a unified interface for key/value stores", similar to what Rack does for web servers, and as Yehuda Katz explains, "libraries that want to provide sugar around key/value stores (e.g. Rails and Merb's caching support) can use Moneta as their backend".

Out of the box, Moneta supports a file store, memcache store, in-memory store, the xattrs in a file system, DataMapper, as well as the aforementioned Tokyo Cabinet (through rufus-tokyo, a "ruby-ffi based interface to Tokyo Cabinet and Tokyo Tyrant").

Read more about Moneta on Yehuda's blog or take a look at the github repository.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Key-value stores lack a fundamental concept by Emil Eifrem

Hi,



Key-value stores are nice and I believe they are an appropriate complement/replacement for RDBMS in some scenarios (that are becoming more and more common). On the plus side, key-value stores have:


  • A flexible data model that can easily capture semi-structured information (increasingly relevant in a web 2.0 / ugc / decentralized-info-creation world).


  • A schemaless approach that allows bottom-up, data-first design rather than the pre-defined and static model of the relational database.


  • A data model that lends itself extremely well to interfacing over REST and to JSON-like serialization. See CouchDB for an excellent example of this.



One thing they lack, however, is semantics for expressing how things are related to each other. It's easy to say "these are the attributes of object n." But no support[1] whatsoever for saying object n is CHILD_OF object k, CONTAINED_IN object l, MEMBER_OF object m and MARRIED_TO object o.



You can certainly encode that information in the value (foreign key-esque) but there's even less built-in functionality for processing it than in the relational database (which at least has joins, for all their problems).



How entities are related to each other is an incredibly important part of the semantics of a domain. On a philosophical level, I guess one could even say that knowledge is how concepts are related to each other. I believe it's fundamental to a data model to support that, in particular in this increasingly connected web 2.0+ era.



In a graph database like Neo4j, relationships are first-class citizens. They connect two nodes and both nodes and relationships can hold an arbitrary amount of key-value pairs. So you can look at a graph database as a key-value store, with full support for relationships.



Feel free to check out Neo4j.org for more information.



(Disclaimer: I'm part of the Neo4j team.)



1] As defined by Stroustrup: A data model (he said language) is said to support a feature if it provides facilities that make it convenient (reasonable easy, safe and efficient) to use the feature.



-EE [who posted this without preview ("error 500") so I hope the formatting isn't messed up]

Re: Key-value stores lack a fundamental concept by Emil Eifrem


-EE [who posted this without preview ("error 500") so I hope the formatting isn't messed up]


Ok, so that was annoying. InfoQ team: Please fix preview. Tried logging in and out, browser restart and all kinds of voodoo but always got "Error 500 -- Could not execute action".

-EE

Re: Key-value stores lack a fundamental concept by Anders Nawroth

As we're talking Ruby here, I should mention the Neo4j JRuby bindings created by Andreas Ronge: github.com/andreasronge/neo4j/tree/master

Re: Key-value stores lack a fundamental concept by Rashid Vali

Hi, Emil

I think graph DB is a choice of the future. Is that possible to compare Tokyo Cabinet and Neo4j from viewpoint of speed and efficiency?

And how can I start playing with it?

Thank you,

Rashid

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
BT