I wrote "I don't know if there's a use case. I have never had one come up in my own projects." I don't work for Facebook or Google, perhaps they have a use case. I guess I could assume there's a use case because the tools exist and people use them, but in my experience I have not had a need for Mongo or any NoSQL database.

I'm not dismissing the tools out of hand -- I haven't used them except to play around with tutorials. I am pretty sure a lot of people start out with Mongo or whatever without having a use case defined and without having good reasons to eliminate the tried-and-true RDBMS solutions. "Use something cool and new" is not a use case. "I've read on slashdot that SQL databases don't scale" is not a use case.

> I haven't used them except to play around with tutorials.

And yet you feel the need to lecture others on their choices ?

Wow you are something.

I'm not sure if Cassandra and Bigtable are "document" databases in the same vein as MongoDB. These guys are more like turbo-charged key-value stores - which is quite different. They trade in the ability to manipulate data for an ability to scale out linearly and have no singular point of failure (and of course various other trade-offs). Cassandra nicely gives you composite columns and column-key sorting, but that's about all you're going to get.

"NoSQL is simply a buzzword. It basically means 'anything but the old and trusty MySQL server in the attic', which includes a lot of alternative storage mechanisms. Even a simple text file can be considered a NoSQL solution"

http://stackoverflow.com/questions/4255895/why-googles-bigta...

I'll add that email and Facebook postings and Instagram photos don't require the same kind of data consistency and durability that medical records, bank transactions, or rail car movements require. If Google loses some old emails or Facebook loses the last thousand "likes" on a Jersey Shore fan page that's not much of a catastrophe, and they don't guarantee their data anyway. For those use cases Mongo or Cassandra et al. may be the right fit.

I work on a app that stores documents (PDFs) in Amazon S3 containers, and sometimes those documents get lost or inaccessible for some reason. We have backups for those. The only consistency requirement there is that the PDF opens and the name matches the name in the RDBMS. That's a much lower bar for consistency and durability than our credit card transaction data, for example.

This is complete and utter nonsense.

Facebook and Instagram itself I imagine would care VERY much if data went missing as it would mean not just (a) user data going missing but (b) potentially huge inconsistencies in the social graph.

Unless you have some evidence that those companies do not care about data durability ?

What? It's the absolute truth. If someone's wall post or tweet goes missing, it's totally inconsequential.

"Social graph" - LOL.

You think FB doesn't consider durability and consistency essential? With almost one billion users?!

Wow.

Whether it is consequential or not is completely beside the point. As is whether you understand the "social graph".

Eventual consistency, yes. What I'm saying is if a few pics disappear for a half hour while things resolve themselves, nobody is going to care... or likely notice.

It's not a bank.

By the way, I believe social networking is mostly bullshit, which is my "LOL" at the "social graph".

Eventual consistency however provides no guarantee of consistency unless it is backed by absolute local consistency on every node. Don't you run into CAP theorem problems otherwise?

Sure. But if a person or a photo data object goes missing ?

Facebook has different data stores for each of their features so I imagine the loss of a person would be pretty nasty as would a photo data object that multiple people have tagged or commented on.

My point is that when you are the size of Facebook, Twitter etc a loss of data in 0.001% of cases equates to a LOT of data and relationships.

If it is that important, they'd be using an ACID-compliant solution, right?

You don't use Best-guess Attempt at Sorta-consistent Eventualities for important data ;-)