Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As someone who first encountered relational databases and SQL at uni in the early 90's, and who has spend a goodly slice of a fifteen year career working with MS SQL Server, I'm probably a textbook example of the people who, according to NoSQL enthusiasts, "have SQL as my hammer and see everything as a nail."

So, to broaden my horizons, I'd like to do some sort of mess-around project using one of these NoSQL databases, as a learning experience.

Question is, though, which one should I mess around with?

  • MongoDB seems to be one of the best known and most respected
  • Raven DB? It's getting some buzz and Hibernating Rhinos have made stuff I respect.
  • CouchDB, since it's part of the Apache project?
  • something else?

I don't have a problem to solve, a project to complete, or a client to satisfy, so I'm not asking which might be best suited to any particular purpose. Just recommendations based on quality, potential, and perhaps most importantly, availability of good docs, guides, tutorials, screencasts, etc. Oh, C# / .NET is my field of expertise, so looking for something which fits that well, e.g. has C# examples in its documentation.

Any tips?

share|improve this question
    
This could be off-topic. If you didn't commit for the DBA proposal, wait until next week to post this question on dba.stackexchange.com –  bigown Jan 4 '11 at 18:07

5 Answers 5

up vote 2 down vote accepted

There are several variations of NoSQL databases.. The ones you have listed are from the DocumentStore category. Redis is from the key-value part of the NoSQL family. Fundamentally they both follow the principles of NoSQL, but do things a differently.

Structured data may be better suited for the DocumentStore family compared to Key-Value variation(Redis).

Maybe a good way to test, would be to implement the same project using two(or more) different NoSQL solutions.

Oh, my suggestion would be to actually use RavenDB since it's native .Net. No third party libraries that wrap operations. No, which wrapper library should I use. The mailing list, based on what I recall, is really active and in general I think this project is gaining momentum. Constant updates, new features etc etc. Plus, it's Ayende's baby who I think does not ever sleep - so if yo need support at ungodly hours that won't be a problem -:)

share|improve this answer

I love MongoDB. I even ended up moving my blog to use it for storage.

MongoDB is a designed to be a scalable, high performance database. It is not designed for situations where strict formats need to be applied. It supports atomic inserts which makes it highly suited for real time data aggregates. It has support for standard indexes, sharding, and even commercial support. It models itself after the idea that databases are specializing and you can't create something to please everyone. It uses the JSON document data model to provide cross service support easily and fast. By removing transactional semantics from standard database design you strip most of the "fat" from traditional SQL processes. This comes at a cost however, you can't create foreign keys or constrain the data like you can in SQL. Systems modeled after transactional systems (think banking or corporate records) won't be efficient in Mongo as they are in other systems.

Yep, written by me

I've heard decent things about CouchDB, however not played much with it myself. I haven't heard great things about it, but Apache projects are for the most part decent.

Standard RDMS are not bad at all. If you need transactional logs and SQL queries go for them. The advantages you have is everything is relational, small size, lots of features, giant community support, and there aren't many surprises. They are solid development tools.

Some people think NoSQL means No - SQL. It's supposed to mean Not Only SQL. There are things out there that help greatly when you need to change the table structure on the fly, or where you might not even know what you'll need to store. This flexibility gives you speed and low overhead, but you loose some of the richness relational databases provide. For instance you can't do cross collection queries in MongoDB (SQL JOIN).

There is a tradeoff, and it's not minor by any means. I would, however, encourage you to play with MongoDB. They even have an online shell that you can test out. (Note: It's a JavaScript shell, you can write functions and loops and fun stuff).

share|improve this answer
    
Thanks for the answer Josh! Yep, I'm good on the "Not Only SQL" thing, and I'm certainly not looking to learn something in the hope that it will be a replacement for SQL Server. I see the two approaches as very much being suited to different types of data storage, and feel a bit like I'm hamstrung by using my SQL Server hammer to hammer in screws sometimes. –  Carson63000 Oct 8 '10 at 4:22
    
Just a note if you planning to use it as a replacement. MongoDB has a 32 bit limitation -blog.mongodb.org/post/137788967/32-bit-limitations –  Ahmad Oct 8 '10 at 4:59
    
@Ahmad - cheers, it's been quite a while since I needed to care about 32-bit systems, though! :-) –  Carson63000 Oct 8 '10 at 5:38
    
@Carson63000 - the reason I mentioned it though is that while 64bit is the future, 32 bit will be around for a long time to come. –  Ahmad Oct 8 '10 at 5:43
    
@Ahmad: You're digging up posts from last year! That was pushing forward to releasing v1.0. MongoDB can run as 32 bit OR 64 bit. –  Josh K Oct 8 '10 at 13:01

There is also OrientDB a open source document-graph dbms with commercial friendly license (Apache 2). Simple API, SQL like language, ACID Transactions and the support for Gremlin graph language. Uses binary and RESTful/HTTP protocols. The SQL has extensions for trees and graphs.

share|improve this answer

MongoDB seems to be considered one of the most easy to get up to speed on, although I always thought CouchDB's API was very straight-forward, particularly if you're familiar with HTTP already.

If it were something I was seriously thinking about for production, I'm not sure I'd go with MongoDB.

Personally, I think Riak looks like one of the most interesting of the noSQL bunch. You may also want to look at a graph DB such as Neo4j for something different again.

share|improve this answer
    
Thanks for the tops! Neither Riak nor Neo4j look very friendly to .NET development, though. :-( –  Carson63000 Oct 8 '10 at 5:36
    
That 4square fiasco was a result of many issues, follow the discussion on the MongoDB mailing list if you would like to learn more. Heck I've had my own issues with MongoDB but the point is it's not currently designed for single-server durability, and it's not designed to handle data as I'm using it. It handles it fine, as long as you are aware of the limitations. –  Josh K Oct 8 '10 at 12:59
    
4square is only the most recent of a lot of mishaps that people seem to have with it. And every time there is someone saying words to the effect "you have to be aware of the limitations" which gives me the impression either a lot of people are not using it for what it was designed for, or 10gen are not doing a very good job of making the limitations understood or establishing best practices. I know it is not designed for single-server durability, which is one of the reasons I would hesitate to use it in production. Thanks for the feedback, Josh. –  Evan Oct 8 '10 at 13:38
    
If you're unsure of how it will do in production look at any number of companies who are currently using it in production. Again, it has limitations and benefits. As long as you are aware of both you're fine. Mongo is little more then a year old (public release in Feb. 2009), there are going to be things that aren't documented and not complete. OTOH they have drivers for just about every language under the sun, a solid community support, and in my opinion an excellent product. –  Josh K Oct 8 '10 at 13:53

If you don't have a specific problem to solve, I recommend that you pick up a list of a dozen or so "NoSQL" databases and try them all out and form your own opinions about them. The next time you walk into an interview or a project meeting, rather than being able to say, "I played a bit with FooDB at home", having a qualified opinion on the "NoSQL" phenomenon and a broader overview of the matter is probably going to help you more.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.