NoSql/Raven DB implementation best practices

Question

I'm investigating a new project which will be a social networking style site. I'm reading up on RavenDb and I like the look of a lot of its features. I've not read up on nosql all that much but I'm wondering if there's a niche it fits best with and old school sql is still the best choice for other stuff.

I'm thinking that the permissions plug in would be ideal for a social net style site - but will it really perform in an environment where the database will be getting hammered - or is it optimised for a more reporting style system where it's possible to keep throwing new data structures at the database and report on those structures.

I'm eager to use the right tool for the job - I'll be using MVC3, Windsor + either Nhibernate+Sql server or RavenDb.

Should I stick with the old school sql or go with the new kid on the block: ravendb?

Answer 1

This question can get very close to being subjective (even though it's really not), you're talking about NoSQL as if it is just one thing, and that is not the case.

You have

• graph databases (Neo4j etc),
• map/reduce style document databases (Couch,Raven),
• document databases which attempt to feel like ordinary databases (Mongo),
• Key/value stores (Cassandra etc)
• moar goes here.

Each of them attempts to solve a different problem via different means, and whether you'd use one of them over a traditional relational store is

• A matter of suitability
• A matter of personal preference

At the end of the day, for the primary data-storage for a single system, a document database or relational store is probably what you want, although for different parts of your system you may well end up utilising a graph database (For calculating neighbours etc), or a key/value store (like Facebook does/did for inbox messages).

The main benefit of choosing a document store as your primary store over that of a relational one, is that you haven't got to worry about trying to map your objects into a collection of tables, and there is less configuration overhead involved in doing so.

The other downside/upside would be that you have to learn something new and make mistakes along the way.

So my answer if I am going to be direct?

• RavenDB would be suitable
• SQL would be suitable

Which do you prefer to use? These days I'd probably just go for Raven, knowing I can dump data into a relational store for reporting purposes and probably do likewise for other parts of my system, and getting free-text search and fastish-writes/fast-reads without going through the effort of defining separate read/write stores is an overall win.

But that's me, and I am biased.