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



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

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)

When to Use RavenDB?

Ayende, the creator of RavenDB:

Typically, it isn’t the only database in the project. In brown field projects, we usually see RavenDB brought in to serve as a persistent view model store for the critical pages, data is replicated to RavenDB from the main database and then read directly from RavenDB in order to process the perf critical pages. For green field projects, we usually see RavenDB used as the primary application database, most or all of the data resides inside RavenDB. In some cases, there is also an additional reporting database as well.

So the quick answer, and the one we are following, is that RavenDB is imminently suitable for OLTP applications, and can be used with great success as a persistent view model cache.

You’d be right say that this is an answer that could be used for most of the NoSQL databases. Looking back at their history, most of the NoSQL databases have started as ways to address problems that people in the field have been having with relational databases. Thus NoSQL databases were mostly used together or at least in the same environment with the relational databases or other storage solutions. Also considering NoSQL databases are an evolving technology, not everyone dropped their existing data stores and started to use them.

Adding NoSQL technologies to existing stacks is the leanest adoption path and the one that minimizes risks. Not to mention that this is the way to accumulate experience with them without putting at risk your business.

Now going back to RavenDB, there are a few titillating features that might arouse your curiosity.

Original title and link: When to Use RavenDB? (NoSQL database©myNoSQL)


What the Heck Are Document Databases?

Julie Lerman in an article offering an overview of 3 document databases (CouchDB, MongoDB, RavenDB):

In my research, I’ve heard a MongoDB expert say that the product’s primary concern is performance. A CouchDB expert pointed to simplicity and reliability (“we want to be the Honda Accord of databases”). And Ayende Rahien, creator of RavenDB, said RavenDB aims for “fast writes, fast reads and world peace.” Each of these document databases has even more to offer than what these sound bites suggest.

With the exception of a few twists (which I’ll point out in this article), these databases provide their data most commonly through HTTP, store their data as JavaScript Object Notation (JSON) documents and provide APIs in multiple languages. The overall concerns are simplicity, speed and scalability. Equally important is that all three are open source projects.

Original title and link: What the Heck Are Document Databases? (NoSQL database©myNoSQL)


Why RavenDB for .NET Development?

Niklas Lundberg summarizes the advantages of using the native .NET document database RavenDB:

As a .NET developer the document database RavenDB is attractive since it provides us with a built-in .NET API, HTTP API and many of the features a NoSQL database can offer. In a web environment the HTTP API is useful because it could eliminate the need for a middle tier for simple scenarios where you don’t need all the features the server side could offer. In RavenDB all documents are stored as JSON and its input and output is also JSON.

And under the covers, RavenDB has a couple more niceties:

Original title and link: Why RavenDB for .NET Development? (NoSQL database©myNoSQL)


Document Databases: Documents, Nothing but Documents

Roman Stoffel published a great intro to documents from the perspective of document databases. While the code is specific to RavenDB, most of the principles exposed apply to all document databases. If you didn’t work with a document database, like RavenDB, MongoDB, CouchDB, make sure you check this post.

I'm a JSON document

Credit Roman Stoffel

Original title and link: Document Databases: Documents, Nothing but Documents (NoSQL database©myNoSQL)

Multi-Document Transactions in RavenDB vs Other NoSQL Databases

“We tried using NoSQL, but we are moving to Relational Databases because they are easier…”

This is how Oren Eini starts his post about RavenDB support for multi-document transactions and the lack of it from MongoDB:

  1. For a single server, we support atomic multi document writes natively. (note that this isn’t the case for Mongo even for a single server).
  2. For multiple servers, we strongly recommend that your sharding strategy will localize documents, meaning that the actual update is only happening on a single server.
  3. For multi server, multi document atomic updates, we rely on distributed transactions.

In the NoSQL space, there are a couple of other solutions that support transactions:

If you look at these from the perspective of distributed systems, the only distributed ones that support transactions are Megastore and RavenDB. There’s also VoltDB which is all transactions. Are there any I’ve left out?

Original title and link: Multi-Document Transactions in RavenDB vs Other NoSQL Databases (NoSQL database©myNoSQL)

RacoonBlog: RavenDB Based Blog Engine

Oren Eini, creator of RavenDB, is drinking his own champaign and migrated his own blog to an engine using RavenDB: RaccoonBlog .

Seems a bit more serious than these other NoSQL-based blogs. Question is though: how many are willing to go with a new blog engine that runs on Windows[1]?

  1. I don’t know if RavenDB works on Mono so you could run it on Linux boxes.  

Original title and link: RacoonBlog: RavenDB Based Blog Engine (NoSQL database©myNoSQL)

RavenDB Filtered Replication

RavenDB gets filtered replication— like the one CouchDB had for a while

One of the features I asked about was the ability to filter out parts of the namespace for replication — instead of the ‘all or nothing’ approach used by default. […] Basically — my aim is to allow the developer to set replication filters — so only a part of a namespace is replicated — rather than the whole db.

For now this feature is available as a forked project on GitHub.

Original title and link: RavenDB Filtered Replication (NoSQL databases © myNoSQL)


RavenDB to Add Auto Sharding


At some point you realize that the data has grown too large for a single server, so you need to shard the data across multiple servers. You bring up another RavenDB server with the sharding bundle installed. You wait for the data to re-shard (during which time you can still read / write to the servers). You are done. At least, that is the goal. In practice, there is one step that you would have to do, you would have to tell us how to shard your data.

In theory, auto sharding would be available in every database. In practice, there are just a few where auto sharding actually works.

Original title and link: RavenDB to Add Auto Sharding (NoSQL databases © myNoSQL)


Why would I use Document Database?

Fitzchak Yitzchaki:

Using a document database like RavenDB will give you the following benefits:

  • Better performance in your application
  • Faster development time
  • Better maintenance experience

Wide claims. To me, document databases’ main strengths are:

  • data modeling flexibility
  • preserving querying capabilities

Everything else is either a consequence of these or an implementation specific improvement which most of the time is the result of another tradeoff.

Original title and link: Why would I use Document Database? (NoSQL databases © myNoSQL)


.NET Rocks Podcast about RavenDB

Carl and Richard talk to Oren Eini, aka Ayende Rahein, about RavenDB. RavenDB is a NoSQL JSON document database. Oren explains how he came to the realization that he needed to build his own data store, and the advantages of document databases over relational databases. Is SQL dead? Not hardly, but RavenDB is an interesting addition to your data solution!

You can listen to it here.

Original title and link: .NET Rocks Podcast about RavenDB (NoSQL databases © myNoSQL)

On Document Databases or Is MongoDB Lacking a Sweet Spot?

Rob Ashton published an article comparing the major NoSQL document databases: CouchDB, MongoDB, and RavenDB, from the perspective that “it’s all about sweet spots”. His conclusions about MongoDB are very interesting:

Mongo on the other hand, is very similar to our traditional databases – with the core difference that data is stored as documents instead of being split out (normalised) across multiple tables. The rest of it all looks very similar – except we lose the ability to do joins across our tables (so complex reporting is out). Reads are fast, but only because Mongo has been micro-optimised to the hilt (just like most database engines), writes are fast, but only because the system doesn’t wait to find out if writes have been successful before carrying on with the next job.

I don’t see it, I don’t see the sweet spot – even if the durability issues are sorted out it’s still just a traditional database with a few less features in the name of gaining a few milliseconds that most of us don’t need.

It achieves fast query speed by storing indexes in memory, which means what Mongo actually gives us is a really slow way to query in memory objects – and heaven forbid you run out of enough RAM to store these indexes on your production servers (ala Foursquare a few months ago). If you’re going to go for an in-memory query store then you’re probably going to use Redis because that’s its sweet spot…

Taking a step back, the two most visible differences between MongoDB and a relational database are:

  • data model (relational vs document-based, non-relational)
  • a different querying language

In reality there are more than just these two — think in terms of ACID — but they are not that obvious upfront.

So, as I said it before, I think MongoDB would be much better positioned if it would be using SQL. That would offer it a “sweet spot”: applications that haven’t worked with relational databases due to the data model. Think about (prototype) applications that are evolving rapidly their data model. Or applications where JOINs have become too complicated, too slow.

Original title and link: On Document Databases or Is MongoDB Lacking a Sweet Spot? (NoSQL databases © myNoSQL)