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

The genius and folly of MongoDB

nyeggen.com

Post reply on HN
Print view View original

251–260 of 280 posts

Re: The genius and folly of MongoDB

#251

Post by chris_wot »

JulianMorrison wrote: post #28
yummyfajitas wrote: post #15

Earlier quoted context omitted.

For what use cases is Mongo the right tool?

You have a smallish number of documents where some particular field of fixed size gets overwritten a lot, the old values are uninteresting, and it wouldn't really be a tragedy if your data got trashed. For example, it's the player's score. You want a fixed-size, rolling backlog of time series data such as logs.

So it's useful for a very limited set of use cases, and you must never be concerned that your data will be lost. I can't believe I'm reading this!

Re: The genius and folly of MongoDB

#252

Post by philwelch »

nostrademons wrote: post #216
philwelch wrote: post #78

Earlier quoted context omitted.

> It's incredibly simple and blindingly fast as long as you stay on one server and you can get several thousand QPS of capacity on that one server (vs. like 10 with a Django/Rails + SQL database solution). Wait, what? Even if vertical scaling was a good idea, scaling is far from the only reason you should have more than one server for anything serious.

Isn't this thread about non-serious use? Pretty much everything I see here is about how MongoDB is only suitable for prototypes, how it doesn't even guarantee writes, how they just want something quick & dirty to build a MVP with. The parent poster asked for something to replace MongoDB with - if the use-case is prototypes and "web scale" startups that don't have users or a product yet, I think a single server with i…

I would say that a MVP should be written in such a way that you don't have to waste time rewriting from scratch once the concept is validated. If you're writing a MVP to be disposable you aren't necessarily launching it on a real server with persistent storage anyway, more likely Heroku or at the very least AWS, but in either case you're well equipped to do the right thing from the outset rather than being forced to totally rewrite your app to enable a real architecture later on.

Re: The genius and folly of MongoDB

#253

Post by willvarfar »

leif wrote: post #232
jpgvm wrote: post #165

Earlier quoted context omitted.

This is going to come off as abit negative but I kinda feel it has to be said. I would first like to say I do love the Fractal tree indexing, very cool and could have alot more intesting usecases outside of databases (I'm thinking logical volume/block storage etc.. I'm always thinking in kernel land..) The problem is that Mongo advertised itself as a database and wasn't one. Once you do that reputation of the product…

I've seen a lot of the rest of their code, and most if it is getting better over time, as they grow they're forced to adopt better habits in order to scale their engineering team. I think you're misunderstanding the type of programmers they are. They didn't use mmap because they are sloppy everywhere, they used mmap because their critical innovation was not in storage. What they really thought was valuable, what they…

As I recall it, all the early noise they generated was their excitement about their hot benchmarks and how good mmap was...

They can try and rewrite the web and remove all the silly benchmarks, but they were the loudest "web scale" cowboys back in the beginning and we remember them for it.

Re: The genius and folly of MongoDB

#254

Post by grmarcil »

Zak wrote: post #249
functional_test wrote: post #191

Earlier quoted context omitted.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

That's fairly unusual; modern cars have a fairly standardized user experience such that there aren't many ways for a car to do something surprising and dangerous that's covered in the manual. I did experience one once though: I discovered that a vehicle had traction control when the system activated during a skid. The computer and I disagreed about the best way to respond, and the surprise did make the situation more…

I'm curious about your desired response during the skid and what the traction control system did differently. Would you mind expanding on that if you remember it clearly?

Re: The genius and folly of MongoDB

#255

Post by programminggeek »

rsynnott wrote: post #142
programminggeek wrote: post #68

I've used MongoDB for various projects and found it nice to use. Lately though, I've found MySQL to be pretty enjoyable too, so honestly, what's all the fuss? It's a database. Nobody writes about the filesystem like they do the database, and yet they do the same job - store and retrieve data.

> so honestly, what's all the fuss? It's a database. Different types of databases are useful for different things. > Nobody writes about the filesystem like they do the database You must have missed the last decade of people going on about ZFS.

> You must have missed the last decade of people going on about ZFS.

I guess I did, what's the big deal about ZFS?

Re: The genius and folly of MongoDB

#256

Post by jpgvm »

leif wrote: post #232
jpgvm wrote: post #165

Earlier quoted context omitted.

This is going to come off as abit negative but I kinda feel it has to be said. I would first like to say I do love the Fractal tree indexing, very cool and could have alot more intesting usecases outside of databases (I'm thinking logical volume/block storage etc.. I'm always thinking in kernel land..) The problem is that Mongo advertised itself as a database and wasn't one. Once you do that reputation of the product…

I've seen a lot of the rest of their code, and most if it is getting better over time, as they grow they're forced to adopt better habits in order to scale their engineering team. I think you're misunderstanding the type of programmers they are. They didn't use mmap because they are sloppy everywhere, they used mmap because their critical innovation was not in storage. What they really thought was valuable, what they…

I don't think the problem is I misunderstand them, I just disagree with them

I disagree with them on what is the minimum viable product for a database. I come a storage and service provider background where failures are treated very harshly (usually death of companies for singular mistakes) so I take releasing a product that stores customer data very seriously.

To be honest this is the biggest attraction for me to RethinkDB. They waited a sufficiently long amount of time with a commercially backed team of very competent engineers that obviously have the required background to sit down and DESIGN a database. The query language generates a non-turing complete language with a clean AST the has all the right deterministic characteristics to implement a powerful planner/optimizer. Their on disk format has been abit in flux but the core design is excellent and you can see that it has been optimized for very fast range queries. Even the API protocol and serialization were designed with care, not to mention the excellent ReQL language and attention to detail when integrating drivers into the host language.

Which is the other thing I tend to dislike about Mongo, it reeks of lack of design. The journalling effort for instance as you pointed out is very adhoc, this goes for GridFS and alot of the other features they have integrated into the codebase. These are smells that I can't ignore when looking at a product that I need to trust with my data.

The counter argument is to not trust it with your data. But I am yet to find a reason where that makes sense where another datastore wouldn't be a better choice.

Re: The genius and folly of MongoDB

#257

Post by pharkmillups »

dboat wrote: post #150
EGreg wrote: post #138

Earlier quoted context omitted.

I sometimes throw out these things as a quick way to get reactions and interesting feedback as to why something is good/bad. For instance right now I know mostly good things about Riak, that's why I posted this ending to my comment.

Having recently rolled out riak into a production environment I can offer some off-the-cuff bullet points: - Mostly easy to work with. Mapreduces can be a big pain to troubleshoot because you can't console.log() in your JS. Didn't try it in erlang. - Being masterless, it has a very good replication story for servers _in the same data center_. It really bit us that there was no good riak solution for syncing data acro…

A bit off-topic, but if you've got a moment I would love to pick your brain a bit more about your Riak usage. Shoot me an email if you're up for it - mark@basho.com

Re: The genius and folly of MongoDB

#258

Post by coffeemug »

orthecreedence wrote: post #194
integraton wrote: post #164

Earlier quoted context omitted.

Agreed. PostgreSQL: ALTER TABLE posts RENAME COLUMN author TO writer; MongoDB: db.posts.update({}, {$rename:{"author":"writer"}}, false, true); (I'm excluding RethinkDB since it's still under development and doesn't have a rename command yet)

I don't think it really needs a `rename` command. The query language supports it without: r.table('posts').replace(function(item) { return item.without('author').merge({writer: item('name')}); })

That works, but it is a bit annoying to type. We'll add a porcelain command for this soon. See https://github.com/rethinkdb/rethinkdb/issues/881.

Re: The genius and folly of MongoDB

#259

Post by invisible »

ak217 wrote: post #197
rsynnott wrote: post #137

Earlier quoted context omitted.

Most master-slave databases don't do auto-promotion themselves; it's a bit of a minefield. (In particular, in cases of network partition, where some applications servers may have a different view to others on whether the master is dead or not).

OK, but that's a different concern. If a database admin manually switches a master (called a primary in Mongo), then someone is responsible for deciding what to do with queries that are in flight. In Mongo, the driver drops them, which is less than optimal. It certainly is a hard problem for writes, but not so for reads. To your point, I think deployments on modern architectures generally want the ability to scale ou…

I think dropping reads is just as unsettling as dropping writes in production.

Also, MongoDB does let you elect a primary via setting a priority. Really, it should be a requirement because sometimes mongo nodes will switch due to a dropped packet (or this is all I can assume at least) and the arbiter just randomly picks a node when there aren't priorities.

Re: The genius and folly of MongoDB

#260

Post by nasalgoat »

edvinbesic wrote: post #201
CoffeeDregs wrote: post #198

Earlier quoted context omitted.

Grandparent seems to make a valid argument. it's more like launching a shuttle mission Given how much we spend time talking about MVPs, Lean Startup, etc, I think people on this site are trying to avoid launch a shuttle mission. [Often] They're looking at building startups and are looking for both time-tested and new-but-advantage-providing technologies and techniques. At first glance, MongoDB appears to be advantage…

I agree, but if you reach that point isn't that one of those good problems to have?

I assure you, having to spend 75% of your administration time dealing with MongoDB problems, taking you away from other critical tasks, you'll see it's not really a great problem to have.
Post reply on HN