Earlier quoted context omitted.
no longer (but only a few months)
Though I believe it still has a per-collection lock.
[1] http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...
51–60 of 111 posts
Earlier quoted context omitted.
no longer (but only a few months)
Though I believe it still has a per-collection lock.
[1] http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...
Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low leve…
I think there are legitimate reasons to use a "NoSQL" solution rather than MySQL. I'm more interested to know in what use cases Mongo kicks it's competitors asses? What are it's competitors, even? I'll admit that the NoSQL world is a slightly blurry mess to me, with different products seemingly optimised for different cases.
If you have a use case that centres around storing document style data then MongoDB will be better suited.
Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low leve…
Mongo isn't so important to this question as ODB vs RDBMS. Here's some light reading: http://en.wikipedia.org/wiki/Object-relational_impedance_mis... MongoDB is just ODB, and MySQL is just RDB. Besides, postgres is the real future!
It is the hardest out of all databases I've used to cluster, replicate, shard and manage. And the database world is moving towards scaling horizontally rather than vertically. I can push a button in say CouchDB to replicate and shard. Try doing that in PostgreSQL.
Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low leve…
IMO there is no rational explanation to this phenomena other than: people are different. Some get bored with stored procs and want same hassle but in another form.
Let me guess. You would build a skyscraper using a trough and cement in a bucket ?
Earlier quoted context omitted.
MongoDB kicks ass in the following situations (real projects I did as a freelancer): - dealing with semi-structured input (forms with some variability) and storing as a document, all while being able to query across the data - used as a store to provide very flexible ETL jobs (with ability to upsert, filter/query, geonear etc) For those situations, I would definitely use MongoDB again. As a RDBMS replacement, I would…
To slightly rephrase the OP's question: In what use cases does mongo kick postgres's ass? To the two points you mentioned: - semi-structured input can be saved as hstore type or as json type; - and for flexible jobs, you can use pretty much any popular language - PL/R, PL/Python, even PL/C if performance is really critical.
The inconsistent reads in replica sets is something we've come across with MySQL read slaves as well. I think it's a gotcha of that whole model of replication, rather than a MongoDB-specific issue.
I'm not aware of any database that solves this problem. Is there one? As far as I know, mysql reads must be distributed to the slaves at the application level, which has no knowledge of master/slave inconsistency. I suppose the time delta between master and slave can be queried, but that still doesn't protect from race conditions/inconsistent reads. This is actually why we chose to only utilize slaves for data redund…
http://www.postgresql.org/docs/9.1/static/warm-standby.html#...
Earlier quoted context omitted.
I think there are legitimate reasons to use a "NoSQL" solution rather than MySQL. I'm more interested to know in what use cases Mongo kicks it's competitors asses? What are it's competitors, even? I'll admit that the NoSQL world is a slightly blurry mess to me, with different products seemingly optimised for different cases.
MongoDB is a JSON document store. Almost all other NoSQL are key/value type stores. If you have a use case that centres around storing document style data then MongoDB will be better suited.
Earlier quoted context omitted.
To slightly rephrase the OP's question: In what use cases does mongo kick postgres's ass? To the two points you mentioned: - semi-structured input can be saved as hstore type or as json type; - and for flexible jobs, you can use pretty much any popular language - PL/R, PL/Python, even PL/C if performance is really critical.
Just because you can write an app using assembler doesn't mean it is the best way to do it.
Besides, SQL sounds more high-level than map-reduce to me.
Earlier quoted context omitted.
IMO there is no rational explanation to this phenomena other than: people are different. Some get bored with stored procs and want same hassle but in another form.
Yes. There is no rational explanation for people using the right tool for the right job. Let me guess. You would build a skyscraper using a trough and cement in a bucket ?
Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low leve…
Eventually consistant replication is not unique to MongoDB, most DBs have an async replication option. Using "not Mongo" won't really solve it.
The contentious area isn't really that Mongo does this, it's because for whatever reason the people trying it don't expect Mongo to do this.