Two Reasons You Shouldn't Use MongoDB
ethangunderson.com
Two Reasons You Shouldn't Use MongoDB
1–10 of 28 posts
Re: Two Reasons You Shouldn't Use MongoDB
#2On the topic of the global write lock, you can run mongostat and see what the write lock percentage is at any given time. How much throughput you can squeeze out of a server is partially dependent on your sync delay setting.
If your disk is saturated during a sync due to a lot of writes, you might see the write lock at 100% for several seconds and everything will momentarily grind to a hault. If you set sync delay to zero and just rely on the OS to sync, you'll never see this happen.
We're using MongoDB in production and have a few boxes setup. One runs without sync delay and is used to process feed data. If Mongo crashed, and the data was irrevocably lost, it wouldn't really be the end of the world as the data only hangs around for about ten days anyway.
The second box runs with a sync delay and is used to store session data. In either scenario, Mongo is designed to be run with a slave at all times since it's not single server durable.
Regarding performance, the feeds box without sync delay can consistently write 25,000 records per second without ever going above 75% write lock. I find that pretty amazing. Doing preliminary benchmarks and performing batch writes that completely lock the server, I was getting about 250,000 writes / second.
Re: Two Reasons You Shouldn't Use MongoDB
#3People should stop looking for silver bullets that are a) "web scale" (intentionally in quotation marks) and b) super secure/durable/consistent/whatever. It's all trade offs. MongoDB makes sense for some data but not others. Its weaknesses are its strengths and vice versa. Same goes for SQL databases.
We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lost in a server crash. The data really fits MongoDB well and it would have been a nightmare if we were to use an SQL database for this. But for bank transactions we wouldn't even consider MongoDB.
The write lock might be a problem for some people. On the other hand MongoDB supports easy sharding, much easier than with SQL. Sharding allows us to scale horizontally which is a huge plus for our data.
Re: Two Reasons You Shouldn't Use MongoDB
#4People should stop looking for silver bullets that are a) "web scale" (intentionally in quotation marks) and b) super secure/durable/consistent/whatever. It's all trade offs. MongoDB makes sense for some data but not others. Its weaknesses are its strengths and vice versa. Same goes for SQL databases. We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lo…
Unrelated comment: thanks a bunch for the speed optimisations pushed into the ruby mongo driver :)
Re: Two Reasons You Shouldn't Use MongoDB
#5We're running MongoDB in an extremely write heavy environment (web crawling). Another solution for the write issues is to split out a single write connection from all of the other read connections and MongoDB gives the reads execution priority before the writes (in principal, in practice and in my experience it's pretty close).
Again this debate comes down to how you structure your data and picking the best model for that and then figuring out how/if you can deal with its idiosyncracies. The single server redundancy issue has been beaten to death and for any production application should be planned in from the beginning regardless of the database.
Re: Two Reasons You Shouldn't Use MongoDB
#6People should stop looking for silver bullets that are a) "web scale" (intentionally in quotation marks) and b) super secure/durable/consistent/whatever. It's all trade offs. MongoDB makes sense for some data but not others. Its weaknesses are its strengths and vice versa. Same goes for SQL databases. We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lo…
One of the best things to come out the nosql 'movement' is exactly that, no more silver bullets. As much as I like Mongo, I would never blindly recommend it, or any other data store for that matter. It's all about analyzing what your problem space actually needs, and using the best tool to fill that space.
And, yes, the speed improvements to the ruby driver are very much appreciated :)
Re: Two Reasons You Shouldn't Use MongoDB
#7Good points, I can think of a few companies who appear to be using Mongo because it's 'cool' and don't sem to understand the tradeoffs. For the applications I have in mind, there is absolutely no reason they couldn't just use postgres, other than that they want to believe they are 'cutting edge'.
Re: Two Reasons You Shouldn't Use MongoDB
#8People should stop looking for silver bullets that are a) "web scale" (intentionally in quotation marks) and b) super secure/durable/consistent/whatever. It's all trade offs. MongoDB makes sense for some data but not others. Its weaknesses are its strengths and vice versa. Same goes for SQL databases. We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lo…
I fail to see why analytics data seem to be considered "low quality" data ("we don't care if some stuff occasionally gets lost"). As far as I can tell, most businesses out there are driven by metrics which are derived from analytics data... so I don't agree that "it's OK to lose some".
Re: Two Reasons You Shouldn't Use MongoDB
#9People should stop looking for silver bullets that are a) "web scale" (intentionally in quotation marks) and b) super secure/durable/consistent/whatever. It's all trade offs. MongoDB makes sense for some data but not others. Its weaknesses are its strengths and vice versa. Same goes for SQL databases. We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lo…
I fail to see why analytics data seem to be considered "low quality" data ("we don't care if some stuff occasionally gets lost"). As far as I can tell, most businesses out there are driven by metrics which are derived from analytics data... so I don't agree that "it's OK to lose some".
If they use it for statistical analysis then the sample size decrease a bit, but likely not in a significant way. If they lost all their data that would be a bit different.
For instance, I routinely delete web server logs older than 30 days, on the assumption that if I didn't need it in the last 30 days I'll probably never need it. Every now and then this bites me and I need more than 30 days data to test some assumption, then I will just have to wait for a bit. (for events that occur infrequently enough).
Re: Two Reasons You Shouldn't Use MongoDB
#10We're running MongoDB in an extremely write heavy environment (web crawling). Another solution for the write issues is to split out a single write connection from all of the other read connections and MongoDB gives the reads execution priority before the writes (in principal, in practice and in my experience it's pretty close). Again this debate comes down to how you structure your data and picking the best model for…
Interesting, I didn't know that priority was given to reads(in theory anyways). Thanks for the tip!
As for server durability, yes, it has been beaten to death. Yet, I still talk to developers that either have no idea that's how Mongo operates, or don't know what save mode has to offer.