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

Don't use MongoDB

pastebin.com

Post reply on HN
Print view View original

101–110 of 331 posts

Re: Don't use MongoDB

#101

Post by christkv »

Goldcap wrote: post #96
electic wrote: post #32

Earlier quoted context omitted.

Our company is a big data company. So our amazing engineers are responsible for storing hundreds of millions of pieces of data per week AND also crunching and analyzing that data. So basically we need a system where we can have incredible write and read performance but also a system that is elastic in nature. Most importantly, it has to be available. Before I go into more details, MongoDB is great for most people who…

Just reading about your transactional volume, it seems like at it's face MongoDB wouldn't be a good fit for this project. 30k per second is not anywhere MongoDB pretends to live, I think by their own admission. And Sharding in MongoDB, while being called a core feature, was bolted on after core development, probably intended to give Mongo some credibility with those who want it to be more scalable. IMHO if you need t…

there's an initial hadoop plugin for mongo that might be a better fit for doing map-reduce over large datasets https://github.com/mongodb/mongo-hadoop

Re: Don't use MongoDB

#102

Post by va_coder »

CarlHoerberg wrote: post #46
jonpaul wrote: post #30

I've used MongoDB in production since the 1.4 days. It should be noted that my apps are NOT write heavy. But, many of the author's points can be refuted by using version 2.0. Regarding the point of using getLastError(), the author is completely correct. But the problem is not so much that MongoDB isn't good, it's that developers start using it and expect it to behave like a relational DB. Start thinking in an asynchr…

Schema-less is imho a overrated feature. ORMs like DataMapper (Ruby) and NHibernate (.NET) can generate the schema on the fly for RMDBS, so no need for migrations pre-production. But when your application is in production you need migrations even with a "schema-less" db! See, rename a field and "all your data" is lost, unless you migrate the data from the old field to the new one..

Schemaless is awesome. Are you dba or a developer? If you're a developer like me schemaless is awesome because of it's flexibility. I focus less time on the how to do stuff and more time on the what stuff should we do.

I've been using Hibernate for 9 years and I finally came to the conclusion that it's just not worth the pain. When working on RDBMS I'm using straight SQL from now on.

Re: Don't use MongoDB

#103

Post by latch »

Am I the only one who's ever forgotten the where clause in an update or delete statement? For all the proof presented, for all we know that's the cause of their lost data.

Re: Don't use MongoDB

#104

Post by fredoliveira »

chrissanz wrote: post #40
buff-a wrote: post #18

Earlier quoted context omitted.

It works on my machine!

A lot of trolling here, I've never had any issues of missing data. When claiming a db (as big and popular as mongodb) doesn't work, you should include references, company, examples on how to reproduce, etc. Enough said: http://www.mongodb.org/display/DOCS/Production+Deployments

Just as you claim that people who have had problems are trolling, so could be said about your own claim. These people are basing their opinion on their own (negative) experience, while you are doing the same based on your own (positive) experience. How is that any different?

This thread includes numerous examples of people who did indeed have grave issues with Mongo. They're not any less valid that your own example (or the ones you link to). In these topics there's always going to be positive and negative takes, but calling people trolls because - again, like you -they voice their opinion is harsh.

Re: Don't use MongoDB

#106

Post by moe »

antirez wrote: post #26

I appreciate the "public service" intend of this blog post, however: 1) It is wrong to evaluate a system for bugs now fixed (but you can evaluate a software development process this way, however it is not the same as MongoDB itself, since the latter got fixed). 2) A few of the problems claimed are hard to verify, like subsystems crashing, but users can verify or deny this just looking at the mailing list if MongoDB h…

1) It is wrong to evaluate a system for bugs now fixed

I disagree. A project's errata is a very good indicator for the overall quality of the code and the team. If a database-systems history is littered with deadlock, data-corruption and data-loss bugs up to the present day then that's telling a story.

2) A few of the problems claimed are hard to verify

The particular bugs mentioned in an anonymous pastie may be hard to verify. However, the number of elaborate horror-stories from independent sources adds up.

3) New systems fails, especially if they are developed in the current NoSQL arena

Bullshit. You, personally, are demonstrating the opposite with redis which is about the same age as MongoDB (~2 years).

Re: Don't use MongoDB

#107

Post by bdarfler »

electic wrote: post #32
jdagostino wrote: post #25

Earlier quoted context omitted.

what did you end up going with?

Our company is a big data company. So our amazing engineers are responsible for storing hundreds of millions of pieces of data per week AND also crunching and analyzing that data. So basically we need a system where we can have incredible write and read performance but also a system that is elastic in nature. Most importantly, it has to be available. Before I go into more details, MongoDB is great for most people who…

We easily support 10s of millions of writes and reads against Mongo per hour on a very small (single digit) number of shards in the cloud (i.e. crappy disk I/O). While that is around an order of magnitude less than 30k a second I would be surprised if we couldn't scale mostly linearly by adding shards.

P.S. If your stack is KV then you should use a KV store.

Re: Don't use MongoDB

#108

Post by regularfry »

latch wrote: post #73
angelbob wrote: post #44

Earlier quoted context omitted.

And yet he makes some good points. Pretty much all of this is verifiable. I don't agree with a lot of his conclusions, but mostly his data is correct.

Look, I'm not the best person to do this..but...good points? 1 - Default writes are unsafe by default: MongoDB supports a number of "write concerns": * fire-and-forget or "unsafe" * safe mode (only written to memory, but the data is checked for "correctness", like unique constraint violations) * journal commit * data-file commit * replicate to N nodes The last 4 can be mixed and matched. Most (all?) drivers allow thi…

I honestly have no dog in this race, but an argument which boils down to "MySQL is just as bad" is not one I'd choose to pursue.

Re: Don't use MongoDB

#109

Post by bdarfler »

antimora wrote: post #8

I was planning adopt MongoDB for my big project and this post puts some doubts. Is this true? Could anyone confirm or deny this?

Go to 10gens site. Watch some of the videos and see the huge volume of data (in TPS or in TBs) that people are working with. Go on the google group and see what problems people have. Don't take an anonymous post on pastebin as the gospel.

Re: Don't use MongoDB

#110

Post by jmspring »

Somewhat off topic, but mongo recently came up in a design discussion. Some of the points here are intereting to consider/evaluate against the most recent version.

My question is, given Mongo and the other NoSQL solutions, has anyone come up with a comparison of strong and weak points across different application types? Feature lists really aren't always useful - as noted about things like code maturity, etc.

Post reply on HN