Such list would be even more useful with the following classification:

Production ready

• CouchDB
• Jackrabbit
• MongoDB
• RavenDB

Experimental

• OrientDB
• RaptorDB
• SisoDb
• Terrastore

Note: A special mention in this category for OrientDB and Terrastore which even if they might not be largely adopted they are still active projects probably counting a couple of production deployments.

Abandonware

• ThruDB
• CloudKit
• Perservere

Original title and link: 11 Document-Oriented Databases Which Are 8: CouchDB, Jackrabbit, MongoDB, RavenDB (NoSQL database©myNoSQL)

A couple of days before 2009 ended, Salvatore Sanfilippo ( @antirez) has announced his intention to implement virtual memory in Redis. In his message to the Redis user group, he has also mentioned some of the goals or advantages of virtual memory in Redis:

1. If the dataset access pattern is not random, but there is a bias towards a subset of keys (let’s call this subset of keys the “hot spot”), with VM Redis can deliver performance similar to the case where you have in memory only the hot spot, using only the memory required to hold the hot spot.
2. Your hotspot is much bigger than your RAM, but you are willing to pay a performance penalty because you want to use Redis.

Today, Salvatore has reported that the first phase of implementing virtual memory in Redis was completed and the Redis Twitter-clone app is already running on this new version.

According to the initial plan, the first phase is a blocking implementation VM.

This means that Redis will work as usually, but will have a new layer to access keys that will be able to understand if a key is in memory or swapped out on disk: when Redis tries to access an on-disk key, it will block to load the key from disk to memory (this includes not only I/O, but also CPU time needed to convert the serialized object into the memory representation).

Right now it is not yet decided if this is just an intermediary step before implementing a non blocking VM or it will become part of a release.

While I am neither a concurrency nor a Redis expert, I must confess that my previous experience with a similar solution to Redis single threaded approach was disappointing — I am referring to the Jackrabbit, the Apache JCR implementation where we had to circumvent the serialized single threaded access for read only clients. On the other hand, there are other well known systems (f.e. memcached) which are using the same solution (some will point out that as opposed to Redis, memcached is never touching the disk, while Jackrabbit has a behavior much closer to Redis).

Anyway, we will always have around these Redis benchmarks for sanity checks.

The Java Content Repository spec and its open source Jackrabbit implementation were once my favorites (as a proof you can watch my ☞ interview about the InfoQ Architecture) and I continue to believe that they carry a lot of good promises.

Below you can find the presentation on JCR, “The Ultimate Content Store? JCR in 15 Minutes” by Bertrand Delacrétaz, one of the main Jackrabbit developers

@kasthomas

Update: I have received an interesting comment on Twitter about JCR that I’d like to reproduce here in order to allow other readers to clarify it.

JCR is a well written specification. The problem is every impl. of its has sucked in terms of performance, integrity and scaling.

Resources

• ☞ Content Repository for Java technology API Specification
• ☞ Jackrabbit