Not sure we needed another key-value store, but it looks like we might get another one from Gemini Mobile Technologies:

Hibari Cloud Database is a distributed non-relational database management system (Distributed Non-RDBMS) for cloud computing to support explosively growing data volume.

While listing a tar.gz download, the ☞ sourceforge project page also mentions:

Hibari is a distributed, high availability key-value data store that focuses on the “C”onsistency and “A”vailability aspects of Brewer’s CAP Theorem.

Oren Eini has an interesting ☞ post emphasizing the main differences between document databases (f.e. CouchDB, MongoDB, etc.) and key-value stores (f.e. Redis, Project Voldemort, Tokyo Cabinet):

The major benefit of using a document database comes from the fact that while it has all the benefits of a key/value store, you aren’t limited to just querying by key.

One of the main advantages of data transparency (as opposed to opaque data) is that the engine will be able to perform additional work without having to translate the data into an intermediary or a format that it understands. Querying by non primary key is such an example. The various document stores provide different implementation flavors depending on index creation time, index update strategy, etc. Oren goes on and covers the query behavior for CouchDB, Raven and MongoDB:

In the first case (nb indexes prepared ahead of time), you define an indexing function (in Raven’s case, a Linq query, in CouchDB case, a JavaScript function) and the server will run it to prepare the results, once the results are prepared, they can be served to the client with minimal computation. CouchDB and Raven differs in the method they use to update those indexes, Raven will update the index immediately on document change, and queries to indexes will never wait. […] With CouchDB, a view is updated at view query time, which may lead to a long wait time on the first time a view is accessed if there were a lot of changes in the meanwhile. […]

Note that in both CouchDB and Raven’s cases, indexes do not affect write speed, since in both cases this is done at a background task.

MongoDB, on the other hand, allows ad-hoc querying, and relies on indexes defined on the document values to help it achieve reasonable performance when the data size grows large enough. MongoDB’s indexes behave in much the same way RDBMS indexes behave, that is, they are updated as part or the insert process, so large number of indexes is going to affect write performance.

Another good resource explaining the differences between MongoDB and CouchDB queries is Rick Osbourne’s ☞ article.

After RavenDB made his appearance in the NoSQL space we’ll probably have to compare it to the existing CouchDB and MongoDB features.

This is not to say that some of this functionality cannot be achieved with pure key-value stores, but these seem to be focused mainly on single/multi key lookups and most probably you’ll have to build this additional layer by yourself.

Lately I’ve been hearing about a couple of newcomers in the NoSQL space so here is your chance to find out about them and why not provide other readers with some additional feedback about each of them:

kumofs ☞

Kumofs is a distributed key-value store built on top of Tokyo Cabinet and using the memcached protocol.

According to the ☞ project homepage:

• Data is partitioned and replicated over multiple servers.
• Extreme single node performance; comparable with memcached.
• Both read and write performance got improved as servers added.
• Servers can be added without stopping the system.
• Servers can be added without modifying any configuration files.
• The system does not stop even if one or two servers crashed.
• The system does not stop to recover crashed servers.
• Automatic rebalancing support with a consistency control algorithm.
• Safe CAS operation support.
• memcached protocol support.

There already seems to be ☞ success story of kumofs, but you’ll have to take that with a grain of salt as the same company was announcing a success story with Redis for the same problem.

Raven DB ☞

Raven DB is a dual licensed document database for the .NET platform with a RESTful API.

According to the ☞ project homepage:

• Scalable infrastructure: Raven builds on top of existing, proven and scalable infrastructure
• Simple Windows configuration: Raven is simple to setup and run on windows as either a service or IIS7 website
• Transactional: Raven support System.Transaction with ACID transactions. If you put data in it, that data is going to stay there
• Map/Reduce: Easily define map/reduce indexes with Linq queries
• .NET Client API: Raven comes with a fully functional .NET client API which implements Unit of Work and much more
• RESTful: Raven is built around a RESTful API

Orient ☞

Orient comes in two flavors: OrientDB: a document database and OrientKV a key-value store, both running on the Java platform.

According to the ☞ project homepage, OrientDB is a

scalable Document based DBMS that uses the features of the Graph Databases to handle links. It’s the basic engine of all the Orient products. It can work in schema-less mode, schema-full or a mix of both. Supports advanced features, such as indexing, fluent and SQL-like queries. It handles natively JSON and XML documents.

The OrientKV is a:

Key/Value Server based on the Document Database technology and accessible as embedded repository via Java APIs or via HTTP using a RESTful API. Orient K/V uses a new algorithm called RB+Tree, derived from the Red-Black Tree and from the B+Tree. Orient Key/Value server can run in high availability mode using a cluster of multiple nodes partitioned.

Have you tried any of these?

Pincaster ☞

According to the GitHub page, Pincaster is a persistent NoSQL database to store geographic data and key/value pairs, with a HTTP/JSON interface. Unfortunately there’s almost no documentation about the project so I don’t think there’s anything else I could add for now.

Update: hint received from @fs111

While the scenario described by Ben O’Steele’s ☞ article — using Redis for log based analytics — might not be interesting to everyone , it made me think once again about the importance of data modeling in the NoSQL space

With all the fun and excitement around NoSQL, it’s easy (maybe too easy?) to stuff your data in your preferred NoSQL solution due to its simplicity and speed. But, you should step back and think about:

• how to model your data
• what data access patterns will your application need
• how you deal with data integrity/consistency (what happens if two applications will need to access the same data in read/write mode?)
• what is the final complexity, performance, scalability of the solution based on the decisions you’ve made to the above points.

It is only then that you should start saving your data!

Just a few days after posting about the “art” and need for data modeling in the NoSQL world, Basho guys have started a series of articles on Riak schema design.

While the ☞ first post was a bit more philosophical (or call it high-level), the ☞ second one is more hands-on and presents various approaches of modeling relationships with a key-value store or document store. Personally, I’ve kind of liked the Riak links^[1] approach as soon as I ☞read about it.

PS: Guys, I hope you’ve already prepared the beers ;-).

Fantastic presentation by Ezra Zygmuntowicz (@ezmobius) on Redis:

My notes from the slides:

Redis usecases:

• Memcached on steroids
• Tag clouds, leaderboards
• Stat collections, circular log buffers
• Share state between processes
• A/B testing
• REDIStribute your load
• Distributed Lock Manager for process coordination
• Full Text Inverted Index Lookups
• Caching with extra smarts using lists, sets and atomic ops on said structures

Some of these usecases are detailed later in the slides. You should definitely check this great list of Redis usecases.

I’ve heard that there might be a video for this presentation, so I hope that will be published pretty soon as I’d really like to include it here with the slides.

You can find below the text on slides (no formatting though)

• Slide: 1

  Redis

  REmote DIctionary Server

  Ezra Zygmuntowicz

  twitter: @ezmobius

  #redis

• Slide: 2

  · Fast,in memory key/value store

  · STRING,LIST,SET & ZSET data types

  · Persistence via async snapshots orAOF

  · Perfect Data Structure/State/Cache Server

• Slide: 3

  Data Structure Server

• Slide: 4

  Data Structure Server

  Key:String => Value:String

• Slide: 5

  Data Structure Server

  Key:String => Value:String

  Key:String => Value:List

• Slide: 6

  Data Structure Server

  Key:String => Value:String

  Key:String => Value:List

  Key:String => Value:Set

• Slide: 7

  Data Structure Server

  Key:String => Value:String

  Key:String => Value:List

  Key:String => Value:Set

  Key:String => Value:Zset

• Slide: 8

  Operations on any Type

  · Exists,Del,Type

  · Keys,Randomkey

  · Rename,RenameNX

  · Dbsize,Select,Move,Flushdb,Flushall

  · TTL,Expire

• Slide: 9

  Operations on STRING’s

  · Get,Set,GetSet,SetNX

  · Mget,Mset,MgetNX,MsetNX

  · Incr,Incrby

  · Decr,Decrby

• Slide: 10

  Operations on LISTS’s

  · Atomic Operations:

  · Push/Pop

  · Index (array indexing)

  · Lrange,Ltrim,Llen

  · Blpop,Brpop

  · RpopLpush,BRpopLpush

• Slide: 11

  Operations on SET’s

  · Sadd,Srem,Spop,Smove

  · Scard,Sismember,Smembers,Srandmember

  · Sinter,Sinterstore,Sunion,Sunionstore

  · Sdiff,Sdiffstore

• Slide: 12

  Operations on ZSET’s

  · Zadd,Zrem,Zincrby

  · Zrange,Zrevrange

  · Zrangebyscore,Zcard

  · Zscore,Zremrangebyscore

• Slide: 13

  Seems cool, but what are the use cases?

  · Memcached on Steroids

  · Tag Clouds,Leaderboards

  · Stat collections,circular log buffers

  · Share state between processes

  · A/B testing

  · REDIStribute your load

• Slide: 14

  Example:Tagging

• Slide: 15

  Example:Tagging

  SADD article:42 magick

  SADD article:42 unicorns

  SADD article:42 rainbows

• Slide: 16

  Example:Tagging

  SADD article:42 magick

  SADD article:42 unicorns

  SADD article:42 rainbows

  SADD article:12 magick

  SADD article:12 bar

  SADD article:12 qux

  SADD article:12 foo

• Slide: 17

  Example:Tagging

  SADD article:42 magick

  SADD article:42 unicorns

  SADD article:42 rainbows

  SADD article:12 magick

  SADD article:12 bar

  SADD article:12 qux

  SADD article:12 foo

  SINTER article:42 article:12 

  #=> magick

• Slide: 18

  Example: Fair Work

  Scheduler

• Slide: 19

  Example: Fair Work

  Scheduler

• Slide: 20

  Example: Fair Work

  Scheduler

  Each worker node periodically issues:

  ZADD worker:nodes 1.5 hostname

  1.5 is the load ave of the host

• Slide: 21

  Example: Fair Work

  Scheduler

  Each worker node listens for work with:

  BLPOP hostname 10 

• Slide: 22

  Example: Fair Work

  Scheduler

  When a producer wants to issue a work request:

  ZRANGE worker:nodes 0 2 

  returns top 3 least loaded nodes

• Slide: 23

  Example: Fair Work

  Scheduler

  Pick a random node out of the 3 least loaded nodes in order to add jitter so we don’t overload hosts

• Slide: 24

  Example: Fair Work

  Scheduler

  Then issue the work request:

  LPUSH hostname {“work”: {“foo”:”bar”}}

• Slide: 25

  Example: Fair Work

  Scheduler

  This setup uses ZSETS and the load average as a score in order to evenly distribute load across a farm of worker instances listening for jobs with BLPOP

• Slide: 26

  Example:AMQP

  message de-dupe

• Slide: 27

  Example:AMQP

  message de-dupe

  Route messages through 2 separate rabbitmq brokers for redundancy

  Use redis for message de-dupe by tagging messages with a guid

  Use guid as key into redis

  Use SETNX when setting the guid key so first one wins and second messages gets discarded as already received

• Slide: 28

  Other Ideas

  · Distributed Lock Manager for process coordination

  · FullText Inverted Index Lookups

  · Caching with extra smarts using lists,sets and atomic ops on said structures

  · Share data structures between multiple processes like a blackboard/tuplespace

• Slide: 29

  Speed

  · 110k GETS/SETS/second on average linux box

  · Mostly faster then memcached for same ops

  · Event Driven,can handle thousands of clients with epoll/kqueue support

  · Ops happen in memory,persistence is async so everything is very fast

• Slide: 30

  Persistence

  · Async Snapshots with configurable triggers

  · Append Only File: AOF

  · Redis 2.0 Virtual Memory

• Slide: 31

  Replication

  · Built in Master -> SlaveAsync replication

  · Create replication chains as needed

• Slide: 32

  Sharding

  · Client side sharding (like memcached)

  · Consistent ring hashing

  · Special case keys “foo{tags}” for operations on keys that must live on the same server in ruby client

• Slide: 33

  Redactor

  · SimpleActor Library based around Redis

• Slide: 34

  Questions?

After mentioning all these NoSQL releases of the most active and exciting NoSQL week, I thought MyNoSQL should provide a quick reference to all of them.

MongoDB 1.2.2

MongoDB 1.2.2 is mostly a bug fix release as can be seen from the ☞ announcement.

Resources

• ☞ MongoDB 1.2.2 announcement
• ☞ Changelog
• ☞ MongoDB downloads

Project Voldemort 0.70

This new version of Project Voldemort is including one of the most awaited features: online rebalancing. While the ☞ official announcement makes it clear that rebalancing has been extensively tested, I couldn’t find a good description of the rebalancing algorithm.

There are other interesting features in the release that I’d like to mention:

• New failure detector merged into the main branch
• Beta mechanism for restoring all of node’s data from replicas on demand. This is an alternative to a more gradual mechanism provided by read-repair.

I’d really love to publish an article about the Voldemort rebalancing implementation, so please do forward this kind request to anyone that can help. ( @strlen, @ijuma: I hope you are reading this).

Resources

• ☞ Voldemort 0.70 announcement
• ☞ Release notes
• ☞ Voldemort downloads

Terrastore 0.4

While version change sounded like a minor release, the latest version of Terrastore, the partitioned and elastic document database built on top of Terracotta, features quite a few interesting new things:

• New, configurable, server-to-master reconnection procedure and improved graceful shutdown procedure for server nodes.
• New socket-based internal communication layer, improving multi-node performances and lowering resource consumption.
• New transparent rerouting of client requests in case of failing nodes.
• Improved rebalancing in case of nodes leaving or failing.

I must confess that if I’d be managing Terrastore releases and knew that these features are well tested, I would definitely jumped a couple of versions!

Resources

• ☞ Terrastore 0.4 announcement
• ☞ Changelog
• ☞ Terrastore downloads

Riak 0.7.1

Riak 0.7.1 seems to be mostly a bugfix release, with a pretty cryptic ☞ announcement (at least for someone not familiar with the Riak source code).

Resources

• ☞ Riak 0.7.1 announcement

It looks like initially I have misunderstood what FluidDB is by calling it a “Wikipedia of databases“. A ☞ post on the FluidDB blog has clarified it for me, so I came up with another definition: “a persistent post-it database service in the cloud”.

While reading the blog post — and leaving aside the fact that as any NoSQL solution it came up with a Twitter-related application — I have found myself getting really excited at the idea. But then, I have realized that:

1. there must be someone creating such an application
2. the associative pattern suggested by FluidDB, while being nice will have to be extremely carefully implemented in the app
3. (this is the most interesting from our NoSQL perspective) there doesn’t seem to be anything unique in FluidDB that would make such a usecase non-applicable to any other NoSQL solution.

Let me clarify it a bit. Basically the article introduces the idea of being able to associate metadata with any kind of information and keep this metadata under clear access rules. In my opinion this is just a simple associative relationship (think key-value stores) that could be implemented using any of the NoSQL solutions we are covering here. Moreover, I tend to think that document databases, like CouchDB, MongoDB, Riak or Terrastore would offer natively a lot of flexibility on the metadata “(un)structure”

Am I wrong?

Taking a look at a fascinating FluidDB usecase that seems to be easily supported by any NoSQL solution. Or not?

A couple of days back I’ve read ☞ a blog post with what I’d call an extremely catchy title: “Why I Think Mongo is to Databases what Rails was to Frameworks“. While the 7 reasons presented in the article are not wrong by themselves, I think that the features mentioned are not so unique to MongoDB.

But let’s take them one by one…

1. Migrations are Dead

[…] migrations are so last year.

Throw a new key into any model and you can start adding data to it.

The whole thing about migrations is related to the complexity of mutating RDBMS imposed fixed schema. In other words, any schema-less solution, being it a document database or a key-value store or even a schema-less RDBMS will show the same benefit.

2. Single Collection Inheritance Gone Wild

By using inheritance, they all share the same base keys, validations, callbacks and collection.

Before looking at inheritance we’d need to firstly separate state and behavior. And then separate behavior into behavior that can be implemented close to the data by behavior that belongs to the object/app model.

Behavior characteristic to the object/app model is not important here as it has nothing to do with the data store. The kind of behavior that can be implemented close to the data (.f.e validations) have been long supported by RDBMS by means of simple data type definitions, constraints or even triggers.

So we are left with mapping inheritable state to data store. As we already know, key-value stores are most of the time completely unaware of the data structure and so inheritance has no meaning there. For approaches where the store must be aware in some way of the data structure, I’d say that over years RDBMS and ORMs have come up with an extremely well designed approach for handling it and I’ll just mention three basic strategies: table per class hierarchy, table per subclass, table per concrete class. In case you’d like to read more on this I’d recommend this Hibernate (Java ORM) ☞ doc.

5. Embedding Custom Objects/Hash Keys/Array Keys

For the next three points, I have reversed the order as I do see them as specialized cases of this more generic one.

Mongo natively understand arrays […] you can even index the values and perform efficient queries on arrays

As if array keys were not enough, hash keys are just as awesome.

What is that you say? Arrays and hashes just aren’t enough for you. Well go fly a kite… or just use an embedded object.

Storing custom object was “always” possible, even if we are including here key-value stores or even RDBMS (nb it is obvious that document stores can handle this scenario). Over time, the most concerns expressed related to custom objects where in terms of efficiency/performance of storing/fetching such data and data layout (nb what I mean is how transparent is to operate with such an object).

So I’d say that the real questions/feature here would be:

• does the engine have an optimal strategy for storing/fetching this sort of ‘objects’? (f.e. how does it deal with array size modifications, etc.)
• in case your app needs to access details of such ‘object’, does the store support it? (f.e. can I filter results based on such on ‘object’ field value(s)?)
• in case such ‘objects’ are used to model relationships, how is your engine helping you avoid the N+1 query issue?

6. Incrementing and Decrementing

I see incrementation/decrementation as just a particular case of the generic “read and modify value” scenario, which is supported by both RDBMS and column-based stores (nb you can correct me on this one as I haven’t checked them all). There is an additional characteristic of this operation that is probably making the difference: atomicity. An even more generic feature that would fit this scenario is the ☞ compare-and-swap.

7. Files, aka GridFS

Mongo actually has a really cool GridFS specification that is implemented for all the drivers to allow storing files right in the database. I remember when storing files in the database was a horrible idea, but with Mongo this is really neat.

Well, I guess everyone tried at some point to store files into MySQL or other RDBMS. The whole issue related to it was the performance of the operation and how handy the API was.

In the end, please allow me say it once again that my intention is neither to argue against MongoDB features nor to deny how important these features can be for an application, but rather to clarify that these features are not unique to MongoDB. And if I misinterpreted any of these please feel free to correct me.