Live data from Hacker News

Things I wish I knew about MongoDB a year ago

snmaynard.com

51–60 of 111 posts

Re: Things I wish I knew about MongoDB a year ago

#51
post #39

Earlier quoted context omitted.

no longer (but only a few months)

Though I believe it still has a per-collection lock.

It has per-database locking. Per-collection is being worked on but no planned date yet. [1]

[1] http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...

Re: Things I wish I knew about MongoDB a year ago

#52
post #25
post #5

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.

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.

Re: Things I wish I knew about MongoDB a year ago

#53
post #5

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!

PostgreSQL is the PAST and it will forever remain there until it solves its biggest problems.

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.

Re: Things I wish I knew about MongoDB a year ago

#54
post #7
post #5

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.

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 ?

Re: Things I wish I knew about MongoDB a year ago

#55

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.

Just because you can write an app using assembler doesn't mean it is the best way to do it.

Re: Things I wish I knew about MongoDB a year ago

#56
post #8

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…

Any platform that supports synchronous replication?

http://www.postgresql.org/docs/9.1/static/warm-standby.html#...

Re: Things I wish I knew about MongoDB a year ago

#57
post #25

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.

not to be persnickety but its a BSON document store. Theres a difference.

Re: Things I wish I knew about MongoDB a year ago

#58

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.

Very tempted to ask "In what way does postgres compare to an assembler and mongodb to a high level language?" but I think I'll just assume that you're trolling.

Besides, SQL sounds more high-level than map-reduce to me.

Re: Things I wish I knew about MongoDB a year ago

#59
post #7

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 ?

Are you trying to give us an idea of what it's like to build an even moderate sized app without transactional consistency and with mapreduce? Because that is what it sounds like to me.

Re: Things I wish I knew about MongoDB a year ago

#60
post #30
post #5

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.

An option is not a default, though, so using Postgres or MySQL absolutely would solve the problem of returning with success before persisting the data.

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.

Post reply on HN