NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Jackrabbit: All content tagged as Jackrabbit in NoSQL databases and polyglot persistence

A Human-Readable Jackrabbit Persistence Manager Prototype for Orientdb

Jackrabbit still has a very special place in my heart. I’ve fought it many times, sometimes losing, most of the time winning. But for over 7 years now, it is still the main storage engine serving the content of InfoQ. So this OrientDB engine for Jackrabbit by Thomas Kratz caught my attention:

This has some limitations, as jackrabbit will still access only one node at a time, being able to traverse the graph at the storage level is simply not intended by the whole api. But it works, it’s readable, can be modified at the db level easily.

Original title and link: A Human-Readable Jackrabbit Persistence Manager Prototype for Orientdb (NoSQL database©myNoSQL)


11 Document-Oriented Databases Which Are 8: CouchDB, Jackrabbit, MongoDB, RavenDB

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

Production ready


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.


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

Comparing Jackrabbit (JCR) and CouchDB

During Berlin Buzzwords NoSQL event, I was asked to compare Jackrabbit and CouchDB, so I hope this will offer a more structured and complete comparison.


Redis Virtual Memory

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.

Presentation: The Ultimate Content Store? JCR in 15 Minutes

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


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.