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

A Year of MongoDB

speakerdeck.com

Post reply on HN
Print view View original

41–50 of 133 posts

Re: A Year of MongoDB

#41

Post by thedufer »

ericcholis wrote: post #16
dmytton wrote: post #14

A few comments on the problems: * CPU bottleneck. The mongod is no usually bound by CPU except for building indexes on existing data (which shouldn't really happen in production). The issue he's talking about is contention between the web server (or workers) and the mongos. This isn't anything unexpected. It's recommended to put the mongos onto the application server and then you scale this by adding CPUs initially b…

Agreed on all counts. Sounds like he is complaining more about issues with VM performance than MongoDB performance on VMs. The joins statement kills me. If somehow the database design requires joins, Mongo is fast enough to run two queries and then let you work with them in code.

> If somehow the database design requires joins, Mongo is fast enough to run two queries and then let you work with them in code.

That's definitely not true. What if you were planning on filtering after the join? You may find yourself pulling millions of records. The bandwidth alone would bring you down. I work with MongoDB, and once in awhile I really miss joins. You can't emulate joins in any reasonable amount of time in Mongo.

Re: A Year of MongoDB

#42

Post by FraaJad »

ims wrote: post #38
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…

Zach Holman has written about this: http://zachholman.com/posts/slide-design-for-developers/ In fact, this slide deck was extremely reminiscent of his style, down to the font and some other details. I wouldn't be surprised if the person who designed this deck was influenced by some of Holman's previous presentations.

eh.. Mitsuhiko is known to have good eye for design. see his Flask website etc.,

Re: A Year of MongoDB

#43

Post by shin_lao »

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…

I think the big problem is that most "NoSQL" engines are naive in their approach, thinking that the people at Oracle, Sybase, IBM, etc. are stupid.

Very few people need scalability beyond what a regular RDBMS can do. So yes, RDBMS have limits, but you'll most likely never reach them.

Re: A Year of MongoDB

#44

Post by kbenson »

bsg75 wrote: post #12
kbenson wrote: post #8

Earlier quoted context omitted.

Sometimes the decision of what technology to use and the task of making it work for your needs are entirely disconnected.

Unless you make a technology decision without understanding what you need to make it work.

My point was, sometimes you, as the the person who needs to make it work, weren't the one that chose what to use. You have a job, to use this tool for this task. Do what you can.

Re: A Year of MongoDB

#45

Post by jeffdavis »

dmytton wrote: post #14

A few comments on the problems: * CPU bottleneck. The mongod is no usually bound by CPU except for building indexes on existing data (which shouldn't really happen in production). The issue he's talking about is contention between the web server (or workers) and the mongos. This isn't anything unexpected. It's recommended to put the mongos onto the application server and then you scale this by adding CPUs initially b…

"[EBS is] fine as a basic file store but should never be used for databases."

Doesn't Heroku use EBS for all of their postgres databases?

It may be the case that postgres works better on EBS than mongo does. Postgres has a traditional write-ahead log that minimizes (and spreads out) block writes and hides latencies. Mongo does not.

Re: A Year of MongoDB

#46

Post by rubinelli »

bsg75 wrote: post #12
kbenson wrote: post #8

Earlier quoted context omitted.

Sometimes the decision of what technology to use and the task of making it work for your needs are entirely disconnected.

Unless you make a technology decision without understanding what you need to make it work.

... which is why any company with an "Architecture Group" has lost its way. When you have a small group that is rewarded with the job of playing around with new technologies and pushing them to the rank and file to implement, bad technical decisions will follow.

(I have a rant for the "Scrum Group", aka "the Agile Police", but I'll save it for another opportunity)

Re: A Year of MongoDB

#47

Post by danielrhodes »

The problem with most of these databases is that they are trying to do too much.

Either the database is great for ad-hoc queries and flexibility or it's great for performance and scale.

Re: A Year of MongoDB

#48

Post by cmircea »

monstrado wrote: post #25
cmircea wrote: post #17

Earlier quoted context omitted.

Seems RethinkDB is still relational. Meh. If you're using C#, I'd recommend RavenDB.

1. RethinkDB is a document orientated database, you store data very similarly to how you would in MongoDB / CouchDB. 2. Relational == Meh? Please elaborate, we're all waiting.

The relational model is not suitable for what most people are using relational databases for.

That's why there's a whole bunch of ORMs, with varying degrees of magic. It's also the reason some people were crazy enough to use relational DBs for key-value storage (eg. Reddit).

Re: A Year of MongoDB

#49

Post by cmircea »

nissimk wrote: post #23
cmircea wrote: post #17

Earlier quoted context omitted.

Seems RethinkDB is still relational. Meh. If you're using C#, I'd recommend RavenDB.

RethinkDB sounds like it's document oriented from their site: "RethinkDB is built to store JSON documents, and scale to multiple machines with very little effort. It has a pleasant query language that supports really useful queries like table joins and group by, and is easy to setup and learn." Also not sure why relational == Meh. RthinkDB does sound promising though not ready for primetime. The following (critical)…

My apologies, I thought RethinkDB was a relational database; the mention of joins gave me the thought, as I don't know of any other non-relational database that directly supports joins.

Re: A Year of MongoDB

#50

Post by cobbzilla »

eranation wrote: post #29
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…

All I can say is this: if the saying "Always plan to throw away your MVP" is true, then I can't see any other storage solution other than MongoDB (or a similar schema-less document storage DB) for MVPs. The speed of development and flexibility are simply worth it. Yes, it is hard to refactor a live product and move it from MongoDB to MySQL / Postgre but was done before and you only do that if you get traction, so its…

You make a VERY big "if" in your first sentence, one that (admittedly anecdotally) I've very rarely seen hold true in tech companies. Much more often, the MVP becomes the product, and all those shortcuts and poor design decisions come back to kill your productivity when it becomes necessary to refactor foundational tech/designs that have metastasized throughout the codebase.

I am curious if this is other folks' experience as well, or do you actually throw out the MVP and start all over at some point? If so, at what point do you make the break?

Post reply on HN