Hacker News Reader

Comment by nkh | Hacker News Reader

From the article:

A lot of NoSQL solutions are about solving specific problems. MongoDB is a general solution which can (and probably should) be used in 90% of the cases that you currently use an RDBMS.

As I use don't use any NoSQL solutions today, can someone list out a few of these cases where I am using an RDBMS and I should be using MongoDB?

View on HN

I'm wondering about this too. For almost everything i work on, the data being in the correct format, written to disk, and stored reliably is more important than the speed or other advantages of Mongo.

I have a hard time understanding responses like this and, in the end, they make me think that people a) really don't understand some of these new data technologies and b) are just as much on the anti-bandwagon as those that sit on the latter.

For people using MongoDB daily, their data is in the correct format, it is persisted to disk, it is stored reliably and it is fast. On top of that, it gives them flexibility as their web app changes and new features and data structures are added, it is easily viewed and manipulated in JSON-format, and if and when the day comes that they need serious scaling, it helps there as well. Also, in the world of EC2, it is straight-forward to set up replica sets to offer redundancy.

All these conversations sound eerily familiar to the Java guys bashing Ruby and Ruby on Rails about five years ago. If you want to stick with what you have, then no worries. I just think people should be excited that over the last couple of years, the "golden hammer" approach to storing data has finally been overtaken and developers have a choice about what technology best solves their data problem.

Actually i've used a few "NoSQL" databases in tons of projects and come to the conclusion that traditional relational database systems are more appropriate for many, many tasks. I really like mongodb and will continue to use it, but not for serious projects as i just don't see the tradeoff being worth it.

Thanks for the ad hominem attack though.

I have first-hand experience with MongoDB silently eating my data (yes, I was using the 64-bit version) which I realized a week earlier when I noticed half the dataset missing.

The reputation (specifically of Mongo) is probably not undeserved.

I am not knowledgeable of your situation, but I am curious about your set up, the intentions you had when you were storing things and other factors in MongoDB not storing your data. Also, I am curious how long ago this was...what version of MongoDB you were using and if you were checking getLastError after the write (assuming you wanted that behavior).

I am not denying your experience, just curious about the whole picture.

I have a writeup here:

http://www.korokithakis.net/posts/using-mongodb-for-great-sc...

I really don't see how you couldn't replace MongoDB in that post with any other database and still be presented with the same issues: - adding indexes slows writes down and increases memory requirements - running queries with poor / no indexes will cause you to have I/O constraints and an unhappy CPU - it seems like your data set was better suited for a graph db like neo4j than a document db or RDBMS.

As for the data corruption, I didnt see you mention if you were checking for a response on saves or not.

I think the problems you experienced were due much more to the fact that you apparently had more data than the machine could handle, not necessarily the database engine used.

MongoDB, the "blame the user" database

See the subsequent writeup on SQLite and how it handled the same dataset magnificently. About the checking of responses, if you read the article you will see that previously stored data just went away, it wasn't failure to store outright.

Given that you didn't know better than to not use 1.3.* initially I find it hard to take your continued propagation of your posts on MongoDB seriously.

If it's common knowledge not to use 1.3.*, why isn't that anywhere on the first page of google when searching for mongodb or mongodb 1.3?

Just curious what the magic incantation is for this information.

Yep, that pretty much invalidates the fact that the stable version of Mongo silently corrupted data.

If only we could make database software that didn't hold grudges!

When you want to do many small real time operations against your data. The model fits well with most web sites (the unit of work for a given request tends to be quite small). Loggin also comes to mind as does some basic geospatial work. I think for most cases it does what a RDBMS can do but with less friction (you'll still use an ORM/ActiveRecord, but it'll be a much more lightweight).

Why don't you check out mongly.com/tutorial/index and get a quick feel for it?

That makes sense, but it is certainly not 90% of what I use an RDBMS for as the author stated. Especially if most of the things I do are not real time web. I will take a look at the link above, as I am curious about it. But I am still struggling for use cases.

By the way, thank you for your comment. I up-voted it.

Because it's "web scale".

Reply on news.ycombinator.com