Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I wish I knew about MongoDB a year ago

snmaynard.com

Post reply on HN
Print view View original

21–30 of 111 posts

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

#21

Post by mgummelt »

splix wrote: post #18
orthecreedence wrote: post #15

Earlier quoted context omitted.

Riak does. You say, when writing, "please don't return until this data is replicated on 2 servers." And when reading, "please only return a successful read if this data is read from 2 servers." So you have R = 2, W = 2, R+W = 4, and if your replication (N) val is 3, you're fine (you're always going to get consistency if R+W > N). Riak is cool.

MongoDB has such feature (maybe its depends on driver, but at least JVM drivers have - http://api.mongodb.org/java/2.9.1/com/mongodb/WriteConcern.h... ). As for me, it's mostly the quesion of perfomance, and application architecture, most time you don't want to wait until it's replicated to slaves.

As far as I can tell, WriteConcerns don't protect from inconsistent reads in all cases. It looks like the most conservative setting is Majority, but even then there is no assurance that reads won't occur during the replication, nor that they won't occur to one of the minority of non-replicated servers.

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

#22

Post by dude_abides »

thibaut_barrere wrote: post #13
dia80 wrote: 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…

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.

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

#23

Post by mattparlane »

dia80 wrote: 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…

My number one reason for choosing MongoDB is replication that just works out of the box and doesn't require either a read lock or shutting down the master to set up a new slave.

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

#24

Post by mgummelt »

orthecreedence wrote: post #15
mgummelt wrote: post #12

Earlier quoted context omitted.

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…

Riak does. You say, when writing, "please don't return until this data is replicated on 2 servers." And when reading, "please only return a successful read if this data is read from 2 servers." So you have R = 2, W = 2, R+W = 4, and if your replication (N) val is 3, you're fine (you're always going to get consistency if R+W > N). Riak is cool.

Does Riak support distributed transactions? If not, I don't see how they handle the possibility of a read occuring during the replicated write.

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

#25

Post by untog »

dia80 wrote: 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.

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

#26

Post by sgolestane »

jandy wrote: post #19
thibaut_barrere wrote: post #13

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 elaborate on the semi-structured input point: Monogo and it's kin are great for EAV systems ( http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%... ), where your entities can have an arbitrary number of fields (often user defined). Trying to build this kind of system in a traditional RDBMs can be quite tricky.

Since we are a mysql shop, for this use-cases I serialize and store the form as xml in a CLOB column. For any field that needs to be searched on, I create an additional column. Disadvantage of this is you can't run mysql queries against the data stored in the CLOB column.

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

#27

Post by joevandyk »

thibaut_barrere wrote: post #13
dia80 wrote: 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…

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…

fwiw, postgresql 9.2 supports a json datatype. you can efficiently access/query json fields using plv8 (http://code.google.com/p/plv8js/).

so you could have:

  create table form_results (                                                                                
    id serial primary key,                                                                            
    data json                                                                                         
  );
http://pgeu-plv8.herokuapp.com/ has more information.

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

#28

Post by dleblanc »

diminoten wrote: post #11
dia80 wrote: 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!

Not sure what Wu-Tang has to do with this, but....

Seriously though, is Mongo an ODB, or a document oriented database? ODBs/OODBs imply a much different use-case and functionality, and I think we ought not conflate the two.

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

#29

Post by nerfhammer »

mgummelt wrote: post #12
lars512 wrote: 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…

This is called semi-synchronous replication

http://dev.mysql.com/doc/refman/5.5/en/replication-semisync....

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

#30

Post by mrkurt »

dia80 wrote: 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.
Post reply on HN