11–20 of 123 posts
Wow, how many "Goodbye, MongoDB" stories are coming? The last days had several ones. Not sure if this is already a trend?
The trend is this: any loved technology that's been around a little while (Rails, Node, Mongo, etc) makes for dramatic farewells on hackernews. It's not unlike supermarket tabloids.
Wow, how many "Goodbye, MongoDB" stories are coming? The last days had several ones. Not sure if this is already a trend?
The trend is this: any loved technology that's been around a little while (Rails, Node, Mongo, etc) makes for dramatic farewells on hackernews. It's not unlike supermarket tabloids.
There is no single way to control the memory usage using system tools except maintaining mongod instances on dedicated virtual machines without running further services. There are numerous complaints from people about this stupid architectural decision from various side and 10gen is doing nothing to change this brain-dead memory model. Can someone explain to me why this is actually a big issue? Except for really tiny…
Wow, how many "Goodbye, MongoDB" stories are coming? The last days had several ones. Not sure if this is already a trend?
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…
> 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.
There is no single way to control the memory usage using system tools except maintaining mongod instances on dedicated virtual machines without running further services. There are numerous complaints from people about this stupid architectural decision from various side and 10gen is doing nothing to change this brain-dead memory model. Can someone explain to me why this is actually a big issue? Except for really tiny…
It seems like the problem is that you're not using MongoDB in a sharded setup to begin with. For good or bad, MongoDB targets the scale where you need sharded and replicated setups. In other words, a large enough operation to require multiple servers for data storage. If you need the opposite of that, which is multitenancy, MongoDB is not going to be a good fit.
On the other hand, MongoDB has always been sold as a rapid prototyping and easy to iterate datastore, which is attractive for people working on small projects. Then they have an "oh shit" moment when they run into operational issues.
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…
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…