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

31–40 of 111 posts

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

#31

Post by mrkurt »

mgummelt wrote: post #21
splix wrote: post #18

Earlier quoted context omitted.

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.

You can set it to the total number of slaves you have and ensure data is on all of them. Normally that slows writes down enough that it's undesirable, though.

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

#32

Post by sausagefeet »

mattparlane wrote: post #23
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.

As far as I can tell, Riak blows mongo away for this particular criteria.

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

#33

Post by sausagefeet »

mgummelt wrote: post #24
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.

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

No, Riak is nontransactional. But neither is mongo if it's important here. Riak is apparently getting some kind of strong consistency though. Calvin looks interesting for a nosql with distributed transactions.

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

#34

Post by mrinterweb »

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…

Map reduce across sharded servers comes to mind as an advantage. For that matter, horizontal scalability in general is a big advantage that many of the NoSQL data stores have over RDBMS databases.

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

#35

Post by elchief »

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…

When you have so many writes that sharding isn't enough.

When you make changes so fast you need a liquid schema.

When you want to make your boss learn map-reduce so he can query the data.

When the application can take care of integration and not the database itself.

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

#36

Post by varworld »

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.

Riak is cool and what you have described is correct however under failure conditions[1] you may not get this desired behavior.

[1]http://docs.basho.com/riak/latest/references/appendices/conc...

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

#38

Post by lwat »

elchief wrote: post #35
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…

When you have so many writes that sharding isn't enough. When you make changes so fast you need a liquid schema. When you want to make your boss learn map-reduce so he can query the data. When the application can take care of integration and not the database itself.

> When you have so many writes that sharding isn't enough.

Does Mongo still have a global write lock?

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

#39

Post by elchief »

lwat wrote: post #38
elchief wrote: post #35

Earlier quoted context omitted.

When you have so many writes that sharding isn't enough. When you make changes so fast you need a liquid schema. When you want to make your boss learn map-reduce so he can query the data. When the application can take care of integration and not the database itself.

> When you have so many writes that sharding isn't enough. Does Mongo still have a global write lock?

no longer (but only a few months)

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

#40

Post by leif »

elchief wrote: post #35
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…

When you have so many writes that sharding isn't enough. When you make changes so fast you need a liquid schema. When you want to make your boss learn map-reduce so he can query the data. When the application can take care of integration and not the database itself.

This will be obvious, but I work at Tokutek.

> When you have so many writes that sharding isn't enough.

TokuDB does indexed insertions very fast. [1] We've even plugged ourselves in underneath MongoDB (just for fun) and we beat them too. [2]

> When you make changes so fast you need a liquid schema.

TokuDB supports lots of schema changes with zero downtime. [3]

> When you want to make your boss learn map-reduce so he can query the data.

Can't help you there, but I can make you not need to torture your boss that way.

> When the application can care of integration and not the database.

What if it didn't need to?

We also get fantastic compression [4], retain full transactional semantics, and lots of other fun stuff.

Email us if you're curious!

[1]: http://www.tokutek.com/resources/benchmark-results/benchmark...

[2]: http://www.tokutek.com/2012/08/10x-insertion-performance-inc...

[3]: http://www.tokutek.com/resources/benchmark-results/benchmark...

[4]: http://www.tokutek.com/resources/benchmark-results/benchmark...

Post reply on HN