Berkely DB is NoSQL under some, let's say literal, definitions of NoSQL.
neo4j currently is also such a db, a non sql db, a NoSQL.
Normally, though, people expect something more from this NoSQL "movement".
People want "scaling", and elasticity.
We live in the world where today you have 2 users, tomorrow you have 2 million of users, the day after you have only 1000. We also live in a world were people are expecting everything to be working always, and are pretty pissed of if things doesn't respond in seconds (watch Luis C.K http://www.youtube.com/watch?v=8r1CZTLk-Gk)
It's not a surprise that all this hype about NoSQL came out when a number of db implementation were developed which handled replication, sharding, dynamic resizing (add remove nodes) etc
Now put a little bit aside the issue with the word "SQL" per se. Let's focus on the "partition tolerance" feature.
I was always frustrated with the fact that no matter how great my product could be, how perfect the implementations would be, how great my db would be; if my machine/rack/datacenter or section of datacenter wen't down, switches break, network connectivity goes down etc. the users of my application are not able to use it, for them it's down.
This kind of NoSQL, the one that handles partition tolerance, gives you the hope that eventually you will be able to make great software, resisting to this kind of events.
I'm not sure whether by these tools (cassandra, riak etc) I would be able to write an application that actually works better, even in the other cases. Stonebraker is right when he says that there are other more probable causes of errors, and that probably the compromises imposed by the partition tolerance will make your software development so complex you will probably make a lot of other errors and make the production unusable.
But at least there's hope that by using this tools you can make things that survive severe conditions. At least this is why I think people get's so excited about all this.
neo4j currently is also such a db, a non sql db, a NoSQL.
Normally, though, people expect something more from this NoSQL "movement".
People want "scaling", and elasticity.
We live in the world where today you have 2 users, tomorrow you have 2 million of users, the day after you have only 1000. We also live in a world were people are expecting everything to be working always, and are pretty pissed of if things doesn't respond in seconds (watch Luis C.K http://www.youtube.com/watch?v=8r1CZTLk-Gk)
It's not a surprise that all this hype about NoSQL came out when a number of db implementation were developed which handled replication, sharding, dynamic resizing (add remove nodes) etc
Now put a little bit aside the issue with the word "SQL" per se. Let's focus on the "partition tolerance" feature.
I was always frustrated with the fact that no matter how great my product could be, how perfect the implementations would be, how great my db would be; if my machine/rack/datacenter or section of datacenter wen't down, switches break, network connectivity goes down etc. the users of my application are not able to use it, for them it's down.
This kind of NoSQL, the one that handles partition tolerance, gives you the hope that eventually you will be able to make great software, resisting to this kind of events.
I'm not sure whether by these tools (cassandra, riak etc) I would be able to write an application that actually works better, even in the other cases. Stonebraker is right when he says that there are other more probable causes of errors, and that probably the compromises imposed by the partition tolerance will make your software development so complex you will probably make a lot of other errors and make the production unusable.
But at least there's hope that by using this tools you can make things that survive severe conditions. At least this is why I think people get's so excited about all this.