top | item 1224955

Jeremy Zawodny: NoSQL is Software Darwinism

42 points| mark_l_watson | 16 years ago |blog.zawodny.com

29 comments

order
[+] andr|16 years ago|reply
Am I the only one that finds certain aspects of NoSQL databases easier to use than SQL? Despite having used different SQL ORMs and writing two on my own, I'm a big fan of MongoDB. It's fun using it for small projects, too, even if I know scalability and speed won't be an issue.
[+] justinsb|16 years ago|reply
OK - I have to bite. Who writes 2 ORMs? What was wrong with the first one?
[+] mark_l_watson|16 years ago|reply
I agree with you. I mostly use MongoDB with Ruby and mongo_record. I find this combination so easy to use that I don't have to think about it (like driving a car). I always keep MongoDB running as a service on my laptops and it is installed but not always running on my servers. BTW, if you use Ruby, have you noticed how much faster mongo_record accesses MongoDB using Ruby 1.9.1 instead of 1.8.x? (Faster than I expected from the usual 1.9 speedup.)
[+] j2d2|16 years ago|reply
Your comment just made me realize SQL is the new assembly.
[+] justinsb|16 years ago|reply
NoSQL is the duck-billed platypus in the evolution of databases. Absolutely fascinating, provides great material for PhD students, but a total dead end. Might survive in some isolated corners of the world; not one to bet on to be the next dominant species.
[+] DrJokepu|16 years ago|reply
A while ago I have held the same opinion; that is up until I have faced a database problem that genuinely wasn't very RDMBS-friendly so I was "forced" to have a look at the alternatives. Ever since then I have realized that there there are large domains of problems that can be solved a lot easier with "nosql" configurations than with RDBMS systems. I mean stuff that I've used to solve with SQL databases before.

My point is: it is always a good idea to have a larger perspective.

[+] adamt|16 years ago|reply
I was initially sceptical over the NOSQL approach, but I have since changed my mind. Let me be very clear SQL is not dead, and it's the right tool for many jobs.

However, if you want a cheap, replicated, multi-master, write heavy system - there is no simple way to this. Oracle is too expensive, I've used mysql-clsuter and pgpool-II etc, but in my experience they tend to introduce more failure points than they remove (at least in projects requiring a short development cycle).

NOSQL pushes a degree of the complexity of the data model back to the application (e.g. you end up building some of your own indexes), but the data model is often no more complex in the end (less normalised, and greater flexibility of columns).

The reward for this is massively simpler scaling. Something like Cassandra is so much easier to replicate to a multi-master multi-site system than PostgreSQL or MySQL.

If you're building any form of semi-mission critical site (where you don't want to rely on or be tied to a single hosting provider) and you need to be multi-site & replicated from an early point, then NOSQL philosophy has a lot going for it.

That said - I strongly hope that the MySQL/Postgres camp will fight back with a simple replication strategy that just works rather than is an bolt-on/afterthought.

I find it helps to think of NOSQL being about simplifying the datastore to make it easier to replicate. So far I think only Cassandra does a persistent multi-master solution properly, but others will catch up.

[+] gte910h|16 years ago|reply
I contend NoSQL is the introduction of nailguns to scaling up large projects with few consistancy constraints where priorly there were only screwdrivers and hammers.

It's useful in it's arena. As are SQL based solutions in their arena. And there are tons of projects that can be done in either. Anyone who contends either is the only way hasn't spent enough time using the other.

IMO, its the equivalent of panting as opposed to sweating: a functional way to get something done that fits some things quite well.

[+] daeken|16 years ago|reply
While I agree on the NoSQL movement in general (really, how many websites don't fit well on an RDBMS?), there are many useful cases for it. In my case, I'm storing massive binary analysis databases in a key-value store that allows quick graph traversal. Traversing code paths in a standard database or KV-store is insanely, insanely expensive, so a custom solution was really the only route to take.