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

Go Cry on Somebody Else's Shoulder: MongoDB is fine

blog.slyphon.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#31

Post by StavrosK »

gfodor wrote: post #6

The author would have us believe that it's unfair to pick on any piece of software because it "all sucks." They'd also have us believe that complaining about your data disappearing in MongoDB is an unfair criticism, and then takes the logical leap that judging the destruction of data and buggy software somehow has something to do with your own ability to create backups. Generally speaking the people who have been bur…

> Generally speaking the people who have been burned by MongoDB have survived by the fact that they had backups.

I'm not one of those people, MongoDB had silently corrupted half my data a week back without me noticing, so the backups were naturally missing half the data as well.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#32

Post by wisty »

Joeri wrote: post #18
bluemoon wrote: post #16

Earlier quoted context omitted.

As he highlights, it is software it will likely have bugs

Yes, but i've been using oracle databases for almost a decade and have never known it to drop data on the floor through bugs (only through user error). Not saying it doesn't happen, just that it's not a common event. It seems with mongo you should expect dataloss.

Mongo people may say that's a good thing - if you aren't planning on dataloss, you are just begging for a disaster. And Mongo will force you to deal with recovery early on.

That's no excuse for the DB being buggy, but some of Mongo's problems are due to hard design constraints - it's not so easy to make a DB that is fast and reliable, and easy to configure. Other's are due to it being immature. Some of it is concerning - it seems it can crumble under heavy write load - not so great for a DB who's selling point is "fast at scale".

Part of Mongo's charm is how it works on a stock system. For traditional DB's, they cache stuff in RAM, then the OS caches the stuff they cached in RAM and swaps their cache to disk. Then you modify something, and the OS swaps the DB cache from disk to RAM, then the DB tells the OS to write the change to disk invalidating your OS disk cache, which then ... you get the picture. Mongo (and Couch) use the OS's cache, which is suboptimal on a tuned machine, but optimal on something you just threw together.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#33

Post by jakewins »

andrewf wrote: post #21

Can somebody recommend a database with an API like Mongo's, but performance and durability more like Postgresql or Oracle's? What I want to do is throw semi-structured JSON data into a database, and define indexes on a few columns that I'd like to do equality and ranged queries on. Mongo seems ideal for this, but I don't needs its performance, and want durability and the ability to run the odd query which covers more…

First, I would take some of the discussion about MongoDB loosing data with a grain of salt - especially since the really harsh critique is coming from an unknown source, as far as we know, it could be a sinister competitor spreading BS. MongoDB makes the up front choice of performance and scalability over consistency, they have never pretended that was not the case. That does not mean that MongoDB looses data left and right, it means that in the choice between bringing a production app to a halt and loosing data, MongoDB will opt to keep your app running.

Second, and this is a shameless plug, I really believe that the DB I work for (Neo4j) is a good answer to your question. Neo4j makes the same consistency vs. uptime decision that classic RDBMes do. In the choice between bringing a production app to a halt and loosing data, Neo4j will opt for saving the data.

So, to answer your question: Neo4j lets you store semi-structured documents in a manner somewhat similar to MongoDB, with the added comfort of full ACID compliance. It also lets you specify indexes to do exactly what you describe.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#34

Post by sep »

andrewf wrote: post #21

Can somebody recommend a database with an API like Mongo's, but performance and durability more like Postgresql or Oracle's? What I want to do is throw semi-structured JSON data into a database, and define indexes on a few columns that I'd like to do equality and ranged queries on. Mongo seems ideal for this, but I don't needs its performance, and want durability and the ability to run the odd query which covers more…

CouchDB fits the bill. It's all about documents, persistence and defining indexes for range-queries. Keep in mind two things:

1. It's all on the disk. So, while its throughput is excellent (thousands or more requests per second), each individual request has a latency of ~10ms

2. You define your indexes beforehand (called 'views' in couch terminology), and then you can only make simple queries on them - like by a specific key or by a range of keys. It takes some learning.

If you and your app are ok with both, go for Couch.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#35

Post by Djehngo »

pilif wrote: post #4

In my opinion, there is but one feature that a database really must have: whatever data I write into it, if I don't delete it, I want to read it back - unaltered (preferably without needing at least three machines, but I'm willing to compromise) Software that cannot provide this single feature just isn't something I would call database. If it's unsafe default configurations or just bugs. I don't care. Between these t…

For what it's worth the original was a dumb hoax (as was heavily implied by the 10gen CTO's rebuttal comment)

http://news.ycombinator.com/item?id=3205573

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#36

Post by CaptainZapp »

ubernostrum wrote: post #25
cmer wrote: post #9

Mongo is fine until it's not. It's been fine for us for many months, but once you hit its limitations, it's pretty horrible. We're in this situation right now and we're seriously considering moving back to MySQL or Postgres. Basically, "it doesn't scale" unless you throw tons of machines/shards at it. Once they fix a few of their main issues such as the global write lock and fix many of the bugs, it could become an o…

Mongo is fine until it's not. My experience is that this is true of every database system (relational or non-). The thing is that they all break in different ways at different points, and so the smart thing to do is make choices based on that information. The stupid thing to do is write blog posts about how Software Package X sucks and nobody should use it for anything.

I work with databases in extremely high OLTP workload environments since 20 or so years.

We're talking enterprise products, mostly Sybase, some Postgresql and very little Oracle.

Have I encountered bugs?

Sure, tons of them. Some of them grave enough to render the specific version of the database software unusable in the context of the project I worked on.

However, in all this time I probably dealt with no more then 3 - 5 corrupt databases, none of them went corrupt due to a database bug. Usually it was related to hardware failure,

Arguing that database corruption is inherent in the design of the product is, from a database perspective, beyond the pale.

A database "breaking" is absolutely not the same as a database blasting your data into corrupt confetti.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#37

Post by adabsurdo »

pilif wrote: post #4

In my opinion, there is but one feature that a database really must have: whatever data I write into it, if I don't delete it, I want to read it back - unaltered (preferably without needing at least three machines, but I'm willing to compromise) Software that cannot provide this single feature just isn't something I would call database. If it's unsafe default configurations or just bugs. I don't care. Between these t…

> preferably without needing at least three machines

if you don't have such redundancy your data is not safe, no matter what database engine you are running.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#38

Post by rdtsc »

adabsurdo wrote: post #37
pilif wrote: post #4

In my opinion, there is but one feature that a database really must have: whatever data I write into it, if I don't delete it, I want to read it back - unaltered (preferably without needing at least three machines, but I'm willing to compromise) Software that cannot provide this single feature just isn't something I would call database. If it's unsafe default configurations or just bugs. I don't care. Between these t…

> preferably without needing at least three machines if you don't have such redundancy your data is not safe, no matter what database engine you are running.

I see where you are headed but that is bad logic. It is like saying your car may catch on fire anytime or a meteorite can strike so why bother also wearing a seat belt?

Sorry you cannot possibly defend un-acknowledged writes as a default setting on a product that calls itself a database. Saying you need 3 machines anyway.

By coming up with more arguments and excuses as a defense for this design you are actually making the product you are defending look worse.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#39

Post by rdtsc »

bluemoon wrote: post #16
gfodor wrote: post #6

The author would have us believe that it's unfair to pick on any piece of software because it "all sucks." They'd also have us believe that complaining about your data disappearing in MongoDB is an unfair criticism, and then takes the logical leap that judging the destruction of data and buggy software somehow has something to do with your own ability to create backups. Generally speaking the people who have been bur…

As he highlights, it is software it will likely have bugs

Ah! Now a purposeful and bad design choice is touted as a bug after shit hit the fan. Nice try. 5 points for effort.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#40

Post by rdtsc »

wisty wrote: post #32
Joeri wrote: post #18

Earlier quoted context omitted.

Yes, but i've been using oracle databases for almost a decade and have never known it to drop data on the floor through bugs (only through user error). Not saying it doesn't happen, just that it's not a common event. It seems with mongo you should expect dataloss.

Mongo people may say that's a good thing - if you aren't planning on dataloss, you are just begging for a disaster. And Mongo will force you to deal with recovery early on. That's no excuse for the DB being buggy, but some of Mongo's problems are due to hard design constraints - it's not so easy to make a DB that is fast and reliable, and easy to configure. Other's are due to it being immature. Some of it is concerni…

> if you aren't planning on dataloss, you are just begging for a disaster.

General rule for picking products -- if a product, by design is supposed to teach you a lesson about backup strategies, don't use that product.

Post reply on HN