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

231–240 of 331 posts

Re: Don't use MongoDB

#231

Post by einhverfr »

ajsharp wrote: post #163
jvehent wrote: post #123

Earlier quoted context omitted.

> MySQL had a much bigger effect to the database world compared to PostgreSQL And if MySQL never existed, what would have happened ? Would we have all used PostgreSQL in the first place and avoided years of painful instability ? I read here all the time that fashion and ease of use are more attractive than reliability. And we introduce plenty of new software in complex architecture just because they are easy to use.…

> And if MySQL never existed, what would have happened ? Would we have all used PostgreSQL in the first place and avoided years of painful instability ? I think you're missing the point a little. Yes, MySQL is a heap, and having to work with it in a Postgres world sucks. But, the point antirez is making in that comment (at least how I read into it) is that an active user community in ANY project is hugely important i…

I still think that solid engineering on any project begins with the engineering and leadership of a few, and the feedback of many. So yes, community is important, but less important than the core of that community which is necessarily small.

Re: Don't use MongoDB

#232

Post by einhverfr »

fdr wrote: post #183
zzzeek wrote: post #176

Earlier quoted context omitted.

you misunderstand me. I LOVE postgresql. It is the best database ever and I try to use it as much as possible. My only point was, they started out as unstable and untrustworthy just like anything else would.

I agree. There was no WAL logging, for instance. Most people consider 7.4 the first actually-possibly-not-a-terrible-idea release. Then again, Postgres -- the project -- did not try to position itself (was there even such a thing as "positioning" for Postgres 16 years ago?) as a mature, stable project that one would credibly bet one's business on. Lots of early database releases are going to be like Mongo, the questi…

Well, 8.0 is really the first really good release.

However, actually-not-a-terrible-idea is pretty relative, when you look at how the industry has evolved in the mean time. I mean, compared to MySQL at the time, PostgreSQL 6.5 was really not a terrible idea. 7.3 was the first release I didn't have to use MySQL as a prototyping system though.

And with 9.x things are getting even better.

Re: Don't use MongoDB

#234

Post by einhverfr »

bborud wrote: post #90
CarlHoerberg wrote: post #46

Earlier quoted context omitted.

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

ORMs are a pain to use. In addition to know the domain you need to map from and the domain you map to, you now also have to understand the mapping process.

ORMs encourage bad database design and little interoperability on the db level.

On short folks build their db around the ORM instead of vice versa.

Re: Don't use MongoDB

#235

Post by johnx123-up »

endlessvoid94 wrote: post #173
nomoremongo wrote: post #154

Pastebin author here. Refutations are going to fall into two categories, it seems: 1. Questioning my honesty 2. Questioning my competence Re #1, I'm not sure what you imagine my incentive to lie might be. I honestly just intended this to benefit the community, nothing more. I'm genuinely troubled that it might cause some problems for 10gen, b/c, again, Eliot & co are nice people. Re #2, all I can do is attempt to rea…

So why are you doing it anonymously?

For me, the post is very helpful---when MongoDB markets itself MongoDB is a scalable, high-performance, open source, document-oriented database. Written in C++... http://www.mongodb.org/

I presume that anyone would post such content anonymously.

Re: Don't use MongoDB

#236

Post by jacques_chester »

einhverfr wrote: post #230
jacques_chester wrote: post #228

Earlier quoted context omitted.

I was referring to the read/write preponderance. Normalisation optimises write performance, storage space and also provides strong confidence of integrity. But it means lots of joins, which can slow things down on the read side. That's why OLAP came along. Structured denormalisation, usually into star schemata, that provide fast ad-hoc querying. I think part of the enthusiasm for NoSQL arises because most university…

Normalization is formally defined based on data value dependencies. However, because there is no way to set constraints across joins, in practice, the dependencies of data constraints are as important as the dependencies of data values. As far as recursive queries, I am not 100% sure this is ideal either from a read performance perspective. There are times when recursive queries are helpful from a performance perspec…

Your replies so far are excellent. You're pointing out things I've overlooked, thanks.

> However, because there is no way to set constraints across joins, in practice, the dependencies of data constraints are as important as the dependencies of data values.

I don't follow your argument here. Could you restate it?

> As far as recursive queries, I am not 100% sure this is ideal either from a read performance perspective. There are times when recursive queries are helpful from a performance perspective, but I don't see a good way to index, for example, path to a node.

Poking around the Oracle documentation and Ask Tom articles, it seems to be more art than science; mostly based on creating compound indices over the relevant fields. Oracle is smart enough to use an index if it's there for a recursive field, but will struggle unless there's a compound index for other fields. I don't see an obvious way to create what you might call 'recursive indices', short of having an MV.

> Certainly most databases don't do this well enough to be ideal for hierarchical directories.

It'll never perform as well as a specialised system. But relational never will. An RDBMS won't outperform a K/V store on K/V problems, won't outperform a file system for blob handling and so on. This is just another example of the No Free Lunch theorem in action.

My contention is that we, as a profession of people who Like Cool Things, tend to discount the value of ACID early and then painfully rediscover its value later on. The business value of ACID is not revealable in a benchmark, so nobody writes breathless blog posts where DrongoDB is 10,000x more atomic than MetaspasmCache.

Re: Don't use MongoDB

#237

Post by ajsharp »

nomoremongo wrote: post #169
nomoremongo wrote: post #154

Pastebin author here. Refutations are going to fall into two categories, it seems: 1. Questioning my honesty 2. Questioning my competence Re #1, I'm not sure what you imagine my incentive to lie might be. I honestly just intended this to benefit the community, nothing more. I'm genuinely troubled that it might cause some problems for 10gen, b/c, again, Eliot & co are nice people. Re #2, all I can do is attempt to rea…

Some are also (fairly) questioning "why the anonymity?", and "where is the evidence?" Those two things are connected: I can't provide the evidence without revealing identity. And the reason for the anonymity is we still have some small databases with 10gen and a current support contract. I had intended to go public with all this after we had transitioned off the system entirely, but more and more reports have continu…

Are you willing to reveal your and your company's identity once you're completely off of Mongo?

Re: Don't use MongoDB

#238

Post by einhverfr »

Encryptor wrote: post #134

This is textbook projecting. The team deployed an immature database and tried to push its limits, and now they're saying: "it sucks!". Sure, a 2 year-old database is the problem, not your ability to make architectural decisions. Sounds like someone is looking for a scapegoat. They took a risk and failed and this is just a poor way of coping with it. It's OK to publish your experiences on your blog (which they did a f…

I would say however that a significant subset of NoSQL deployments (perhaps even a large majority) are by definition lacking in sound architectural decisions. I'd argue the same goes for ORM-based database access too.....

The failure exists because many developers don't ask a few key questions up front:

1) What exactly can the database do for us? 2) Which of these do we need? For example, is the database going to be a point of integration? 3) What failsafe or security measures do we want to count on in the database?>

These don't always have objectively right/wrong answers but failure to ask the questions leads to poor use of databases regardless of what technologies are chosen.

Re: Don't use MongoDB

#239

Post by willvarfar »

harryh wrote: post #194
willvarfar wrote: post #189

Earlier quoted context omitted.

http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/ You had 11 hours downtime and didn't lose money? What about opportunity cost? Reputation? Now you have to share your secret :) (I guess, if you weren't profitable, you had nothing to lose?)

The 11 hours of downtime was a pretty big deal, but it had very little to do with MongoDB. It was basically a huge failure in proper monitoring.

That's not how everyone remembered it at the time, nor the picture the blog painted. And the mongo monitoring thing is much newer, right? Its like saying that a fire wasn't a big deal because next time there'll be a fire station.

Stockholm syndrome?

Or perhaps investor pressure to close ranks ;)

Re: Don't use MongoDB

#240

Post by tlogan »

We are all engineers and MongoDB is open source. Maybe the easiest way to evaluate the project is to review the source code. This will give at least some idea about quality of MongoDB - of course MongoDB can still be a great product even if code is not written well but it is important indicator.

What is your comment about code written? Is it maintainable? Is it modular? Doe s it seem well written?

Post reply on HN