Hacker News Reader

Comment by sdm | Hacker News Reader

While some of the author's criticisms are valid, some of them are completely wrong:

> Having no option to perform an operation comparable to UPDATE table SET foo=bar WHERE....

What? db.collection.update does exactly this. See: http://www.mongodb.org/display/DOCS/Updating#Updating-update...

MongoDB fit a nice niche for a read heavy mid-scalability db solution. Every DB has it's niche. Trying to use it outside of what it's good for is going to get you burned. If people just did their research before blindly committing to a platform, we'd see a lot less posts like this.

View on HN

Agreed. I found the mapreduce criticisms to be a little off:

> Now instead of fixing a bad implementation or fixing the underlaying architectural issues, MongoDB is moving to Hadoop.

I don't think that's accurate. They have a new "aggregation framework" coming that is meant to replace mapreduce. It could be a wrapper around hadoop, but I couldn't find anything documented about that. I completely agree that a blocking mapreduce is annoying, however, does any framework have a non-blocking mapreduce? I haven't tried many mapreduce implementations out, so this is a genuine question.

I don't believe RavenDB blocks. Instead, it returns the results along with a flag to indicate if any of the source data may have been modified while the operation was running.

You're right, all RavenDB indexing operations (including Map/Reduce) are done on background threads. When you query, it returns a flag (as you say) indicating if the index is currently stale or not.

The aggregation framework is meant to fill a gap between SQLs SUM, COUNT, AVG, etc without requiring a full map/reduce. The Hadoop integrations are unrelated and are just a nice little bonus that they added.

I was wondering if he meant copy fields from one column to another, or to modify a value in a document based on the value in another field. I don't think that's possible in Mongo without writing server-side JS or doing it in your client.

Agree with your general point, though - this seems like they have a product/tech mismatch. Though I'd argue that this isn't a niche - read heavy, mid-scalability is a lot of the web.

Well the other thing is: people act like migrations are the devil.

Yes, moving your data from Mongo to PgSql, MySql, MSSql, Oracle, etc. is going to be difficult.

However: why start with a production level Oracle install anticipating "web scale" when you're not going to have more than ~1k users at launch.

People look to Google and Twitter and Facebook for advice on how to scale. They then apply this advice far before they need to.

I don't think you should plan to be large scale from the get-go. I think you should have a plan for what you're going to do if you get big.

My $.02

I really don’t understand how they used it for 2-3 years without knowing this.

Reply on news.ycombinator.com