NoSQL - do you use it?

I’ve just started to play around with mangoDB which is a free NoSQL “database”

Has anyone else started to use these things? Do you guys think that hosting companies will start providing these as standard on their packages any time soon?

What I’ve noticed is a lot of companies moving to NoSQL, so I thought it best to learn it while it was fresh. Initially I thought it was just super large companies (FB,GOOGLE etc) but it’s smaller ones too.

Actually Google and Facebook and “the large companies” use things like Hadoop to process monsterous datasets.
Then again, it’s not SQL so i guess you could call it NoSQL.

What most NoSQL databases like mongoDB do is create files with a json or xml like string in which the data is stored (you can easily write your own NoSQL database aswell). In fact this means that NoSQL works exactly the same as SQL. Only the format in which the data is stored means that you can easily store and retrieve objects with NoSQL. Hence why NoSQL is suggested to be the next “hot thing” to be used by object oriented applications. With SQL object oriented programmers have to use mappers to translate relational data from a database to objects and vise versa.

There is a bit more involved in writing a good, useful non-relational database than storing json or XML. I’ll add that mongodb is NOT an example of a good non-relational database – it has some serious flaws in the way it treats data.

Personally I’m using a lot of RavenDb. In fact, the default choice going forward here is RavenDb not SQL Server – it is just so much better to work with for most things. It is astounding how much time and effort one went through to jam their “square” data into the “round” relational hole. Losing that cruft has been at least quite refreshing.

ur doin it wrong, lol

:smiley:

I’ve done some playing around with mongodb but not enough to really comment on it. Recently, there was a 2 or 3 part series of articles in MSDN magazine recently describing how to integrate mongodb (and other object db’s) into windows apps with visual studio. It was pretty interesting reading.

I’ll bite. What exactly is doing it right? Keep in mind here is what I’m looking to avoid:

a) Dealing with keeping schemas in synch across a multitude of environments – say a few developer machines plus dev-integration plus QA plus production. This all needs to happen in a manner that the CI server can run – ie, from the command line.
b) Hand-plumbing database code for most cases. No issue crafting complex queries, but typical stuff like selecting an entity should not require any thought.
c) Avoiding hand-plumbing by using complex, leaky abstractions called ORMs
d) All the while maintaining a code-base that is easily testable in an automated fashion, preferably without relying upon a working database to test most of the non-data access parts of the application.

As for mongodb, go watch http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale (NSFW language. Also sad but true). If you are doing .NET, check out RavenDb.

doing it right is, by definition, not wasting time and effort

which was your complaint about relational databases, yes? the part which in post #4 i responded to?

you must’ve been doing it wrong :slight_smile:

also, “ur doin it wrong” is an internet meme

i loves me some internet memes

are you familiar with scumbag steve?

i was thinking of scumbag sql, that’d be hilarious

PROMISES DATA-APP INDEPENDENCE

MAKES YOU HARDCODE ALL ENTITIES

sort of in keeping with your complaint

but, you see, when i explain myself at length, it loses some of the immediacy, wouldn’t you say?

:slight_smile:

There is always more things involved. The point i was trying to make is… when you store data, you do so in a certain data format. Whether you use nosql or sql or whatever. At the end of the day there is no true performance increase from using a relational or non relational database (obviously depending on which database you use). Besides the obvious reason that having the ability to store and retrieve objects directly has advantages when you write object oriented code.

I got the feeling from the original post that the person thought that big companies were switching to things like mongoDb. I kind of tried to explain this was not the case. All those techniques are way to slow for google and facebook.

On the performance side of things, you don’t gain so much straight line performance as ability to scale in ways you just can’t do within the relational model. The basic issue is that, by definition, relational databases are always consistent. Which means updates need to replicate across things before you can read. Which means, when you hit certain web-scale sizes you just can’t use MySql anymore. At least for the OLTP part of things.

Lots of very big companies are using non-relational databases for alot of things. Facebook invented and uses alot of Cassandra, which is actually a 2nd layer cache as everything happens in memcache which one could also call a no-sql database of sorts. Google uses BigTable in many places. You’ll see alot of people talking about Hadoop but that isn’t really a database – it is for crunching data in a distributed manner using MapReduce. Now, if one was to use Hadoop to do some things, one would almost certainly have to embrace a datastore that was distributed to avoid bottlenecks.

All that said, for the sorts of projects most folks are doing here, the compelling reason to use NoSql is not because of some scalability issue but rather because you can directly store and retrieve objects. Once you do a project or two without having to worry about marshalling things to SQL and dealing with all the things that entails you’ll feel alot better.

I completely agree. Which is why I recently started using couchdb which also uses MapReduce on my localhost. Now I just have to wait for cheap webhosts to start support for couchdb.

Good luck with that. Then again, a dedicated *nix VPS is not an expensive proposition. Nor is a EC2 micro instance.

I know but I’m dutch so I am cheap! (have to live up to the expectations of the world)