
NoSql Databases – Part 1 - Landscape - mcxx
http://www.vineetgupta.com/2010/01/nosql-databases-part-1-landscape.html
======
ivenkys
I am not sure what this sort of an article achieves - its neither succinct
enough to be a synopsis nor is it detailed enough to be an in-depth
explanation.

It reminds me of one of those MS-Word Specification documents bandied about in
enterprises. I never could grok one of those , this is no different.

~~~
chris123
You have point, but it's a good first effort. It would be nice to see a short
summary and recommendations at the top, with more info on separate pages or
down below. Could even move this kind of thing over to a wiki (or maybe such a
wiki already exists?).

~~~
ivenkys
Even paginating it would help in the readability, i think.

------
tom_pinckney
I find that I need transactional databases less and less. Whether I
specifically don't need SQL is not clear -- it's a great abstraction for
storing and manipulating data.

Specifically, what I loose with transactions is fault tolerance and
predictable performance while I find I don't really need atomicity in most
places.

Fundamentally fault-tolerance is achieved by having few interdependencies
among computer systems. Transactions makes that really hard to do for
replicated databases and you need replication to be fault tolerant. So usually
people cheat and settle for async replication, but then you really don't have
transaction anymore since different parts of your system are seeing different
states.

Transactions also lead to difficult to debug blocking behavior either due to
deadlocks (btw, where else in computer systems is the advice that you have to
destroy all abstraction and understand the entire locking order of your
program in one place?) or locks getting held too long due to programming
errors etc. I hate when my entire site hangs because a key table has locks on
it due to some transaction getting accidentally left open.

Understanding database consistency levels and their nuances is extremely
difficult and error prone as well. So you may not really be operating in the
pristine transactional environment you thought you were.

Finally, programming to a non-transactional model is actually pretty easy in
most cases. You just have to go into your project thinking about this upfront.
And the decisions you make building a non-transactional site will probably
increase how decoupled all the parts are which will make it scale better
anyway.

------
moe
Wow. That's a lot of information there.

Nitpick; the presentation is almost impossible to digest. A few tables instead
of endless bullet lists would work wonders here.

------
seymourz
Amazon S3 may not be readily classified as a key-value store. It seems better
sit between distributed key-value store and distributed file system.

