Hacker News Reader

Comment by cpleppert | Hacker News Reader

I'm a little blown away by the total lack of technical understanding when it comes to MongoDB. This person is obviously very technical, so why would he have chosen MongoDB in the first place? It isn't like MongoDb's technical shortcomings are a secret. The description of how MongoDb does sharding and distributed queries should have immediately raised red flags to any who has even a modicum of CAP understanding. If it sounds complex, a total hack and impossible to manage it probably is.

For gosh sakes, even the 10gen guys admit MongoDB lost data a year(!) ago. [1] If a database lost data in a single server configuration, why would you trust it as a cluster?

1: http://www.dbms2.com/2011/04/04/the-mongodb-story/

View on HN

Because developers without significant database / data store experience are choosing where to put their data because its "easy to use".

Yes, RBDMS and similar approaches are difficult to work with [1] and introduce "impedance mismatch". Yes joins can be slow. Yes scaling can be difficult and or expensive. But, when choosing where to put data without understanding (or accepting) why the above is difficult is only asking history to repeat itself.

[1] "Database guy here". I know databases and SQL. I would not consider choosing what language to implement a web application tier on, because I don't have enough relevant experience. I focus on what I have battle experience in.

"Easy to use" is a perfectly legitimate criteria to optimize for. For most startups performance/scale is a total non-issue, most of the time even something like berkleydb would do. At most early stage startups developer time is the single biggest bottleneck.

If you make a non-optimal choice upfront you can always migrate to another database later on (database migrations are painful but in practice is something you have to do sooner or later in any case).

(obviously this applies to the scaling argument; if you need transactions you should pick a database which supports them)

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.

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

   If a database lost data in a single server configuration, why would you trust it as a cluster?

Please be serious here. EVERY database has had at one point lost data due to a bug. It doesn't mean that there is some systemic problem that means you should jump ship immediately.

To this day Foursquare who are the ones referred to in the article still use MongoDB:

http://engineering.foursquare.com/2012/11/27/mongodb-at-four...

I was more surprised by a technical post complaining about workers, waiting on io, and context switching. There are ways to handle concurrency and network communication without large amounts of context switching and threads.

Reply on news.ycombinator.com