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

11–20 of 111 posts

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

#11

Post by diminoten »

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!

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

#12

Post by mgummelt »

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 redundancy rather than read throughput at my last company. Inconsistent reads weren't tolerable.

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

#13

Post by thibaut_barrere »

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 wouldn't use it today.

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

#14

Post by mgummelt »

jbert wrote: post #10
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.

One way to resolve it is to mark that user or session (or even just request) "sticky to the master" for long enough to cover your normal replication delay. When we saw it before, ensuring that a given request which issued a write also read from the master was sufficient. (sub-second replication delay).

This may help in the majority of the cases, but many applications also can't tolerate inconsistent reads across users/sessions.

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

#15

Post by orthecreedence »

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…

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.

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

#16

Post by achompas »

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.

I believe Cassandra does as well, not 100% sure though.

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

#17

Post by nevinera »

>Range queries are indexed differently

If I'm reading your description right, this is hardly mongo-specific. Try it in mysql, for example:

(index is [:last, :first])

  select first from names 
  where last in ('gordon','holmes','watson')
  order by first;
An index is an ordering by which a search may be performed - to illustrate, the index for my small table looks pretty much like this:

  gordon, jeff
  holmes, mycroft
  holmes, sherlock
  watson, john
Unless the first key is restricted to a single value, it can't order by the second key without performing at least a merge-sort. They aren't in that order in the index.

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

#18

Post by splix »

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.

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.

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

#19

Post by jandy »

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 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.

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

#20

Post by ash211 »

achompas wrote: post #16
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.

I believe Cassandra does as well, not 100% sure though.

Cassandra does, you can write with a write consistency of W and read with a read consistency of R, and as long as their sum is greater than the replication factor (number of copies to store across the cluster) you have consistent reads. W + R > N.

http://wiki.apache.org/cassandra/ArchitectureOverview#line-1...

Post reply on HN