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

161–170 of 280 posts

Re: The genius and folly of MongoDB

#161

Post by ollysb »

bkanber wrote: post #93
swanson wrote: post #86

Earlier quoted context omitted.

Couldn't you argue that e.g. Postgres and ActiveRecord give you the same rapid prototyping ability but with an easier (and more established) path towards scalability? It is easy to change your schema with migrations at the beginning of a project - just go edit the original ones and nuke your database. And I don't have to worry about properly configuring write-locks, replica sets, or writing map reduce javascript.

Of course you could argue that. But so what? Having an easier path towards scalability is nice, but irrelevant for the vast majority of projects; not every project is going to turn into a startup or a real product or even something you work on for more than a few weekends! The last time you hacked together a blogging engine in Node.js one weekend, were you worried about future scalability, or just playing with new te…

> while it's pretty easy to do schema migrations, it's not easier than _not_ doing them.

I just don't buy this argument, writing and executing migrations is braindead simple and usually takes what, 20 seconds start to finish? Writing the line of code you need for mongo must be about 5 seconds.

edit: I did actually give mongodb a good crack(used on a side-project for 6 months last year) but I found that I actually spent a huge proportion of my time working around things that were missing compared to ActiveRecord. It was a huge net loss for me in terms of productivity.

Re: The genius and folly of MongoDB

#162

Post by leif »

dlau1 wrote: post #151

Can someone comment on how mature rethinkdb is at the moment? I'm considering moving away from MongoDB before I have to implement what seems to be an incredibly complicated architecture to get it to scale on the level tens/hundreds of millions of documents.

RethinkDB is not yet "ready for production use" but reportedly will be soon.

If you're currently on MongoDB but need more performance, concurrency, or compression, please try TokuMX: http://www.tokutek.com/products/tokumx-for-mongodb It's a drop-in replacement server that uses a better storage engine but speaks the same protocol and query language.

Re: The genius and folly of MongoDB

#163

Post by warmwaffles »

yeukhon wrote: post #160

I am so happy Postgres is adding support for JSON. This is a big change. The sole benefit of mongo to me is that you can be flexible with your schema at the beginning. But the consequences are * you have to learn to do indexing right later (if you have to scale) * failure and miss starting to occur (as you scale) * more code to write to manage legacy schema and optional fields The last is painful and ugly. Whereas if…

> I have not seen a good ORM for Mongo

Uh, Mongoid is good. I have used it on past projects. It's nice. (mainly use some form of SQL now)

Re: The genius and folly of MongoDB

#164

Post by integraton »

dodyg wrote: post #154
integraton wrote: post #131

Earlier quoted context omitted.

> You don't need to worry about updating the schema at the db level What's your magic non-db level, supposedly-easier-than-updating-a-schema approach to renaming a field common to all existing documents in a collection, eg, rename an "author" field to "writer"?

This is where a nice query/manipulation language come handy http://www.rethinkdb.com/api/#js

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)

Re: The genius and folly of MongoDB

#165

Post by jpgvm »

leif wrote: post #159
willvarfar wrote: post #21

Varnish famously demonstrated how to use the kernel page cache effectively. MongoDB, though, is Squid-like. Its an interesting comparison. Every single MongoDB step has had the old timers groaning. Even with something solid like Tokutek's storage engine in it, its going to be a hard sell.

I'm an engineer at Tokutek I'm confused by your comment. The beginning acknowledges the fact that MongoDB has a weak storage engine, but your conclusion is that, even with a strong storage engine like ours, there is still a problem. What other problems do you see? Are they something we could work on?

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 is dead forever.

TokuMX is a real database as far as I can see, MVCC, great indexing story etc.

By association TokuMX is probably not regarded as highly as it should be. Which is a shame but it's a people problem, not a technical one. People can very easily lose trust in a technology at which point it's effectively dead, it might take a long time to die due to lock-in but it's dead.

For instance I have recently started playing with RethinkDB over TokuMX almost purely because of Mongo association.

Now technically that might not sound like good reasoning but when you think about the kind of person that writes a database that doesn't fsync your writes by default and relies on the page-cache over doing direct I/O when building a database.. doesn't really inspire confidence in the network stack, the query planner.. or well anything.

If anything it makes you insistent on not having ANYTHING to do with that sort of codebase.

Just replacing the storage engine might actually be good enough, but restoring my trust in the rest of the codebase is almost a forgone conclusion at this point.

Re: The genius and folly of MongoDB

#166

Post by joevandyk »

meowface wrote: post #112
yummyfajitas wrote: post #56

Earlier quoted context omitted.

One viable option: CREATE TABLE mongodb ( key VARCHAR(256) PRIMARY KEY, value JSON );

Mongo (and other document stores) let you do pretty complex querying within JSON objects. Postgres unfortunately doesn't let you do so; that's really the only thing keeping me with Mongo at the moment.

Postgresql 9.3 added json functions.

Re: The genius and folly of MongoDB

#167

Post by [deleted] »

berntb wrote: post #156
integraton wrote: post #144

Earlier quoted context omitted.

> Do you always start with the perfect data structure? I find myself adding, removing, and restructuring schema often. Which is why it doesn't make any sense to claim that using MongoDB somehow eliminates needing to migrate your data as it evolves.

That is easiest [cough, imho] solved with adding a version number to stored records. Since data is not in much of a normal form and there won't be that many joins, it generally is easy to handle in code. Sometimes you have to do update of records with a certain version number. My opinions, for the record: MongoDB is a tool with some use cases. I'm more of an SQL+Memcache guy, if possible, but not religiously if a goo…

[deleted]

Re: The genius and folly of MongoDB

#168

Post by Lazare »

dodyg wrote: post #149
Lazare wrote: post #107

Earlier quoted context omitted.

Well, the obvious answer to your question is: CouchDB! It's a brilliant, underrated database, and hey, it backs NPM! On the other hand, Redis, Cassandra, Riak, and many more are also excellent NoSQL databases. But none of them, including CouchDB, are excellent at everything . What are you planning on making? You can write a lot of different things in node.js. If you're writing, say, a blogging engine you probably sho…

Actually if you are making a blog engine or CMS, a document database is an obvious choice.

I'm a huge fan of NoSQL in general, and document databases in particular. However, I think this is nuts. :) NoSQL is about making tradeoffs; you give up some of the strengths of a traditional RDBMS but in return you get some unique advantages. The problem is, you aren't taking advantage of any of those advantages with a blog...are you?

I really don't see how MongoDB beats Postgres for running a basic blog. And while it doesn't prove anything, I note that Ghost (which has been getting a lot of press as a new, shiny, node.js based blogging platform) is backed by SQLite of all things. Why is it obvious that they should have used a document database instead? What advantages do you think that would have given them? Because of the top of my head I can't think of one.

Re: The genius and folly of MongoDB

#169

Post by rdtsc »

functional_test wrote: post #126
rdtsc wrote: post #106

The problem with MongoDB is their shadiness. The shipped with unacknowledged writes up until not too long ago. In other words you would write to it and there wouldn't be an ok or fail response, you'd just sort of hoped it would go in. They fixed that problem but it was too late. In my eyes they proved they are not to be trusted with data. Had they called themselves MangoCache or MongoProbabilisticStorage, fine, can s…

I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level was very clearly documented and you could always change it as necessary. Surely it would be necessary to read the documentation of a database before rolling it out to production?

> Surely it would be necessary to read the documentation of a database before rolling it out to production?

You buy a car. It comes with brakes disabled because for whatever reasons that also lets it get to a higher top speed. You are expected to read you car owner manual and on page 54 you find that you have to hold "enable brakes" button under the console for 10 seconds to turn on your brakes. Would it vex you that people might be slightly critical of that car. Clearly they are silly for not reading their car manual until page 54.

That "feature" is not something that should be discovered by reading docs or when you get a crash and then load a backup from another week and still get a crash and then you start hitting your head on your desk.

Anything calling itself a "database" should not have shipped with those default settings _ever_. If they did they might have gotten away with it in my book by having a big flashing red warning on the front or download page. I don't remember one.

Re: The genius and folly of MongoDB

#170

Post by ericingram »

mcot2 wrote: post #73

A lot of these downsides are fixed by Tokumx. Real transactions, document level locking, compression and disk optimized indexes. I suggest everyone take a look at it.

I agree. TokuMX has filled many holes in Mongo and (at least in my experience so far) performs very well. It's got great documentation, backed by a brilliant team. As a drop in replacement for mongo binaries, it's really easy to install and offers professional/enterprise support if you need it.
Post reply on HN