NOSQL

Plebs

Anyone using it?

I was introduced to MongoDB recently and, for the applications I'm working on, it's a breath of fresh air compared to MySQL.

Also, JSON objects. I was reluctant at first, but now I can't live without.

paddydub

yes nosql is the way to go
how ****ed is my database:
http://bit.ly/9w91GP

http://architects.dzone.com/articles/what-nosql-store-should-i-use

Collumbo

depends. For main app data, i still like to use MySql.

However, for logging and my own analytics stuff that isn't really core to the main application, i used Amazon SimpleDB. It's a good to work with, but a bit weird at first when getting used to their terminology. It's very very fast retrieving data from hundreds of thousands of rows, and best of all, free, because it will be a good while before I hit the 1 gig when they start charging a whopping 12c per month. :eek:

In short, I like it.

Civilian_Target

Totally agree. I've been mucking about with Couch DB, and it's everything I've always wanted from a hashmap. Frankly, saves a lot of effort thinking about relational dbs, and many of the performance problems too.

Doubly excellent when you use SSDs on the DB machine, because it doesn't suffer from any of the parallelism issues of SQL DBs either

Dr.Silly

Civilian_Target wrote: »

Totally agree. I've been mucking about with Couch DB, and it's everything I've always wanted from a hashmap. Frankly, saves a lot of effort thinking about relational dbs, and many of the performance problems too.

Doubly excellent when you use SSDs on the DB machine, because it doesn't suffer from any of the parallelism issues of SQL DBs either

what paralllelism issues does SQL have ?

amen

thinking about relational dbs, and many of the performance problems too

what performance issues? you can just as easily have performance issues with nosql.

Will your nosql handle 100,000s transactions a second ?
support Terrabytes of data?

Civilian_Target

Dr.Silly wrote: »

what paralllelism issues does SQL have ?

Sure, by guaranteeing both availability and consistency you lock yourself into the ACID transactional model. For each ACID transactional write, you must lock at least the relevant table rows to both read and write. This naturally inhibits DB partitioning, and thus large-scale parallism

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

amen

ACID transactional model

why would you not want to use the ACID model?

In SQL Server (I'm sure Oracle as well) you can partition your data.

MS SQL also support paralllelism.

These new DBs are great but show me a real live system handling 100,000s transactions a minute.

It all seems like XML data bases and object databases from the past.

Have their uses

Civilian_Target

Google BigTable's a pretty good example.

Other examples would be Digg and Facebook (Cassandra), or Last.fm (HBase)

And they're just the ones I can think of off-hand!

paddydub

amen wrote: »

what performance issues? you can just as easily have performance issues with nosql.

Will your nosql handle 100,000s transactions a second ?
support Terrabytes of data?

Yes couchdb can handle petrabytes of data, CERN is using CouchDB on the Large Hadron Collider project
Why Large Hadron Collider Scientists are Using CouchDB

I think nosql is good as it introduces 4 types of databases: Document databases, Key-value stores, Graph databases and BigTable clones
If SQL is best suited to your app keep using it but if you think your data could be better modeled in a nosql database, use the one of the 4 types of databases.
I have been using neo4j which I find very easy to model data in a graph,
Need a graph database like Twitter is built on?
If you need a documents store CouchDb is good
A powerful replicable mobilized database: CouchDB
If you need a key- value store Redis is a good option
StackOverflow Preparing to Use Redis

Dr.Silly

Civilian_Target wrote: »

Sure, by guaranteeing both availability and consistency you lock yourself into the ACID transactional model. For each ACID transactional write, you must lock at least the relevant table rows to both read and write. This naturally inhibits DB partitioning, and thus large-scale parallism

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

This is incorrect.
How many transaction isolation levels does sql server have !!!
Parallelism is fine in SQL Server..

If you know your transaction model you can cater for locking

amen

Google BigTable

interesting. Something new learnt today.

Civilian_Target

I was sent a very interesting new research paper on this topic this morning - you can see the researcher's commentary with a link to the paper here: http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html