A Year of MongoDB • Hacker News Board

Re: A Year of MongoDB

#111

Post by jwilliams » Sat, May 11, 2013, 1:41 PM UTC

My first thoughts when I read this:

1. It's easy to screw up a relational database. I've seen more than a few mature relational databases... Most of them have plenty of sins, near-crippling performance snafus and other horrible legacy. Any database that is big enough and growing enough is a beast to manage.

2. From the slides, I think this guy took "Schema-Less" as a cue to stuff completely arbitrary data into MongoDB. No wonder his indexes went crazy. You still need to think about the data you're storing & the relationships. You need a design whatever database you use.

3. Any relational databases I've seen at scale have a lot of flattening. I've seen intra-day transaction dbs that are completely flattened. If your next port of call is a highly normalised relational database, you're going to hit another wall fast enough.

4. Two Phase commit. Seriously. Forget it. I've spent half my career in financial institutions. Quick, fail-fast processing with a reconciliation process is by far the most common approach. 2PC actually slows you down and introduces another component that gets in the way. It's used very sparingly (and even then, usually causes a world of pain).

Re: A Year of MongoDB

#112

Post by FraaJad » Sat, May 11, 2013, 2:05 PM UTC

Jaigus wrote: post #33

dccoolgai wrote: post #9

Who is still surprised by this? I feel that after 2-3 years of the litany of stories and cases like this, it should shock absolutely no one anymore.

He is a relatively popular programmer so people will still comment on his presentation (even if it is a little redundant at this point). Unsung database veterans like Tony Marston have been saying things like this for years but few people took them seriously.

but have you seen his website? uses frames, comic-sans and talks about COBOL. Obviously, NOT COOL. /s

Re: A Year of MongoDB

#113

Post by gbog » Sat, May 11, 2013, 2:05 PM UTC

The question I think is fundamental but that I didn't see asked nor replied is this: if we had a data store that had full performance, full scalability, etc., would we design it as a relational database or not? Said otherwise: the debate about NoSQL, is it an optimisation issue or a design issue? (Keep in mind pg's article about what would be a language in hundred years)

Re: A Year of MongoDB

#114

Post by the_mitsuhiko » Sat, May 11, 2013, 2:19 PM UTC

ot wrote: post #22

Completely off-topic (well that's my nickname) but I'm seeing on HN more and more beautiful slide decks, from a purely esthetical point of view. This deck has beautiful fonts and a beautiful color scheme, and it is nicely designed. My question is: how are they made? Keynote, Powerpoint, HTML...? Are they made with the help of a graphic designer? They look completely outside of the reach of the average technical devel…

> My question is: how are they made? Keynote, Powerpoint, HTML...? Are they made with the help of a graphic designer? They look completely outside of the reach of the average technical developer. Or do they use a pre-made theme?

author of the talk/slide-deck here. I make all my slide decks with Keynote, primarily because it has the best font rendering and presenter display out of the options available on OS X. They do not use a pre-made theme but I'm always looking for inspiration from other presentations and websites.

Might be out of reach for the average technical developer but that's just because the average developer does not do slides. That stuff can be practiced. My slides got considerably better (I think at least) the more presentations I did.

Re: A Year of MongoDB

#115

Post by treenyc » Sat, May 11, 2013, 2:26 PM UTC

neya wrote: post #19

This is the problem with most of the guys who go with MongoDB. Obviously, this person is very technical, so I am not flaming him nor accusing him, but this is my view of the rest of them who pick MongoDB without exactly having a clue as to why (hipsters) or when they should use a NoSQL db and when they shouldn't. I do not hesitate to admit that I was a hipster sometime back too. I chose MongoDB for many of my project…

If you use java stack like JSP or RingoJS, I would just use H2.

http://www.h2database.com/html/main.html

It bets MySQL and Postgresql in performance.

Re: A Year of MongoDB

#116

Post by AlisdairO » Sat, May 11, 2013, 2:49 PM UTC

nasalgoat wrote: post #108

AlisdairO wrote: post #79

Earlier quoted context omitted.

I suspect the reason that Mongo attracts so much hate is that it's more heavily marketed/evangelised than other NoSQL DBs - so more in the public eye and people expect more from it. Since the reality is that Mongo is not yet a technically strong product (regardless of its merits in terms of ease of use and getting simple things done quickly), it's bound to attract more negative attention.

Having spent the last two years trying to make MongoDB work at large scale and only succeeding because I have a ton of resources (200+ db hosts), I can say it's more than just the spotlight. It is a fundamentally broken product.

Fair enough - I have no direct personal experience with Mongo myself. Coming from a more traditional DB background, what I've read indicates it has a lot of technological flaws, but I didn't want to be too harsh in my judgement without personal experience.

For my own curiosity, what issues caused you the most trouble? The lack of transactions combined with the extremely coarse grained write locking were what put me off the most.

Re: A Year of MongoDB

#117

Post by rubinelli » Sat, May 11, 2013, 3:32 PM UTC

jeffdavis wrote: post #96

threeseed wrote: post #72

Earlier quoted context omitted.

I just don't like the "right tool for the job" argument. Then say the "right technology for the task" then. There is no ONE database that works perfectly in every situation.

When installing a database system, it is rarely a "task". It's usually something that will live a long time and there will be many long-term consequences.

Back in the day, many startups died with a gigantic Oracle database that cost them months of runway, because they had to "think long-term".

Build for what you need now, and just make sure your "central repository of truth" isn't lossy. You can always replicate for specific use cases later.

Re: A Year of MongoDB

#118

Post by jeffdavis » Sat, May 11, 2013, 5:14 PM UTC

rubinelli wrote: post #117

jeffdavis wrote: post #96

Earlier quoted context omitted.

When installing a database system, it is rarely a "task". It's usually something that will live a long time and there will be many long-term consequences.

Back in the day, many startups died with a gigantic Oracle database that cost them months of runway, because they had to "think long-term". Build for what you need now, and just make sure your "central repository of truth" isn't lossy. You can always replicate for specific use cases later.

I'm not saying that you shouldn't make short-term compromises. I'm saying that "right tool for the job" is sloppy reasoning.

Even in the short term, it might be much faster to develop against a good RDBMS than a nosql system. I think many developers are so focused on "abstracting away the data store" that they forget what a good RDBMS can do for them.

Re: A Year of MongoDB

#119

Post by ahoge » Sat, May 11, 2013, 6:26 PM UTC

ot wrote: post #22

Completely off-topic (well that's my nickname) but I'm seeing on HN more and more beautiful slide decks, from a purely esthetical point of view. This deck has beautiful fonts and a beautiful color scheme, and it is nicely designed. My question is: how are they made? Keynote, Powerpoint, HTML...? Are they made with the help of a graphic designer? They look completely outside of the reach of the average technical devel…

I found this very helpful:

http://www.slideshare.net/jessedee/steal-this-presentation-5...

Re: A Year of MongoDB

#120

Post by dindresto » Sat, May 11, 2013, 8:01 PM UTC

astral303 wrote: post #91

These guys are lucky they didn't try Cassandra. That's really Mongo's problem: it's too close to a regular SQL solution. You have a sharded NoSQL data store that performs in-store filtering and sorting? You can run aggregation queries? Compound indexes? Amazing! Tell me more. Moral of the story is unless you can justify a NoSQL datastore for your particular solution and you can live without joins, stick with a regula…

"These guys are lucky they didn't try Cassandra." Could you explain that further? I'm currently using Cassandra for a new project, so this sentence caught my eyes.