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

Two Reasons You Shouldn't Use MongoDB

ethangunderson.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Two Reasons You Shouldn't Use MongoDB

#21

Post by patio11 »

alexpopescu wrote: post #8
FooBarWidget wrote: post #3

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

I use MySql and Redis for persistence, depending on the type of data. Both get written to on a purchase: MySql upgrades the account info, Redis holds my A/B testing stats which just had several tests score points. If the MySQL write fails, I have a CS emergency because my customer can't get what she paid for and I probably just ruined a lesson plan for tomorrow. If of the Redis writes fails, my A/B test results that I won't look at for a week anyhow shift in a way that almost certainly doesn't alter my final decision.

It is absolutely OK to lose analytics data occasionally, and indeed with the variety of ways to bork that (js is off, user agent prefetches undisplayed page, bot action, etc) if your stats aren't robust against it you are screwed anyhow.

Re: Two Reasons You Shouldn't Use MongoDB

#22

Post by smoody »

At the risk of sounding both lazy and naive, if i want to utlize replica sets, do i have to separate each mongodb instance onto a separate hardware box? put another way, if i want to deploy a durable mongodb installation, do i need three or four EC2 instances (for example) running at the same time, all the time?

Re: Two Reasons You Shouldn't Use MongoDB

#23

Post by sreque »

ethangunderson wrote: post #6
FooBarWidget wrote: post #3

People 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 :)

My problem is that I'm not a data storage expert. Do I now have to specialize in this field to be able to choose the appropriate persistence technology for a given problem? I have yet to see a good explanation of when different technologies are more appropriate, as most of the discussions I see usually devolve into some sort of SQL-NoSQL flame war. I would like a good, fair resource to explain the pros and cons of different persistence technologies more clearly.

Re: Two Reasons You Shouldn't Use MongoDB

#24

Post by anto1ne »

smoody wrote: post #22

At the risk of sounding both lazy and naive, if i want to utlize replica sets, do i have to separate each mongodb instance onto a separate hardware box? put another way, if i want to deploy a durable mongodb installation, do i need three or four EC2 instances (for example) running at the same time, all the time?

yes you do. and not only on production. if your dev box with mongo is rebooted unexpectedly, there goes your data.. you'll have to do a db.repairDatabase() or restore completely, which can take hours if you have a lot of data.

Re: Two Reasons You Shouldn't Use MongoDB

#25

Post by code_duck »

j_baker wrote: post #18
code_duck wrote: post #7

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

I'd argue that there are more people out there who could be benefitting from using Mongo but won't because SQL databases are "standard".

I agree. I have a few applications which I suspect could benefit from a non traditional data store. The reason I haven't used one yet isn't that, though, it's simply that I am much more experienced with installing, tuning, maintaining and programming for relational databases.

Re: Two Reasons You Shouldn't Use MongoDB

#27

Post by sqrt17 »

sreque wrote: post #23
ethangunderson wrote: post #6

Earlier quoted context omitted.

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 :)

My problem is that I'm not a data storage expert. Do I now have to specialize in this field to be able to choose the appropriate persistence technology for a given problem? I have yet to see a good explanation of when different technologies are more appropriate, as most of the discussions I see usually devolve into some sort of SQL-NoSQL flame war. I would like a good, fair resource to explain the pros and cons of di…

The questions you should ask yourself are the following:

* Does it matter if you lose the last 5sec. worth of updates? The last 5 minutes? The last day?

If you can lose 5sec. worth of updates, a MongoDB replication pair is just fine. If you can lose a day's worth of updates (or can easily reconstruct the database contents from other sources), you can try out pretty much anything without bad repercussions. If you can't lose anything, you're pretty much limited to the most conservative databases (the SQL bunch).

* What's the most obvious unit of data that you're working with?

If you always update single values (or add things to lists/sets), Redis is an excellent choice. If you have fixed-size records, SQL or one of the table-based options (Cassandra, Hbase) may be for you. If you have documents with substantial internal structure, a document store (MongoDB, CouchDB, or Lotus Notes if you want something expensive and commercial) would be a good option.

* How much data do you have?

If all of your data fits into memory (and for the price of another server, you may well get enough memory to fit all of your data), you can go pretty far with a single server. If it fits on a single set of hard disks, you'd want replication, not sharding, so that the risk of losing data is minimal. If your data is much larger than that, your only hope is a sharding setup - either with SQL+spit+glue, or Cassandra/HBase, or some version of MongoDB where sharding is stable enough for production use (I do remember seeing warnings - so the current version may or may not fit that description).

Re: Two Reasons You Shouldn't Use MongoDB

#28

Post by sreque »

sqrt17 wrote: post #27
sreque wrote: post #23

Earlier quoted context omitted.

My problem is that I'm not a data storage expert. Do I now have to specialize in this field to be able to choose the appropriate persistence technology for a given problem? I have yet to see a good explanation of when different technologies are more appropriate, as most of the discussions I see usually devolve into some sort of SQL-NoSQL flame war. I would like a good, fair resource to explain the pros and cons of di…

The questions you should ask yourself are the following: * Does it matter if you lose the last 5sec. worth of updates? The last 5 minutes? The last day? If you can lose 5sec. worth of updates, a MongoDB replication pair is just fine. If you can lose a day's worth of updates (or can easily reconstruct the database contents from other sources), you can try out pretty much anything without bad repercussions. If you can'…

Thanks for the response. I will mull that over next time I have a say in the matter of how to store data. I think at some point I will also just need invest some time to play with a few of the NoSQL choices to get a better feel for them.
Post reply on HN