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

221–230 of 280 posts

Re: The genius and folly of MongoDB

#221

Post by dodyg »

Lazare wrote: post #168
dodyg wrote: post #149

Earlier quoted context omitted.

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…

How about this list for a start?

1. If you are doing multi lingual site, you can store your multiple language content in a single document instead of futzing around with {lang, content} tables 2. If you want to do custom form/content, it is trivial to do it in a document database instead of relying on key,attribute tables. 3. Just store your theme in a single document, which can include various html templates, css, etc. To export or import a theme is also easy - just stuff the whole document into the db. 4. If you want to add plugins to enhance the capability of your blog/cms, they can have their own nested document inside their target document. Everything is contained.

Re: The genius and folly of MongoDB

#222

Post by gbog »

functional_test wrote: post #184
justinsb wrote: post #148

Earlier quoted context omitted.

Other databases are forgiving; they are configured "safe", even at the expense of speed. The intention is that you can deploy a small system immediately; if/as you grow you will see that the database is going too slowly. You can _then_ look at the performance/safety dials you can tune and choose appropriate trade-offs. These are systems designed for the real world, where people don't read the manual until they have t…

I'm not sure how anyone else could know what my best interests are. There are a lot of real world applications where small amounts of data loss don't matter but latency matters a lot. Any time I deploy something as critical as a database, I carefully read about what it does and how it works. Not doing so is like signing a contract without reading it.

> a lot of real world applications where small amounts of data loss don't matter but latency matters a lot.

I don't understand this reasoning. We are talking about defaults. Defaults are used by people who did not tweak the settings yet. If I am just starting building a thing, I will have bugs and squeaks and I want to make sure I am not fooled by some unreliable data store. I am not likely to need 100GiB/s throughput, but I am very likely to have to hunt bugs, like "I did click on this button but it did not add to the total likes". And I would really really hate it if after half a day of bug hunting I would realize that my data store just didn't store the thing...

Re: The genius and folly of MongoDB

#223

Post by ddorian43 »

annnnd wrote: post #210
rdtsc wrote: post #169

Earlier quoted context omitted.

> 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…

I like your analogy, very fitting. To their defense however they are far from the only ones to do that... I lost about 2h worth of production data with HBase in just the same way - fortunately I didn't want to trust it completely anyway and had my own logs of all transactions on filesystem, but it definitely shattered my trust in that DB (not to mention it was a pain to setup and had no secondary indexes). I use Mong…

doesn't hbase persist in the transaction log every update, using append on hdfs ? or did you have a version of hdfs that didn't have append ?

Re: The genius and folly of MongoDB

#224

Post by nbevans »

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.

I would put it out there by suggesting that you probably have low standards when it comes to databases. Have you used anything else other than MongoDB and MySQL? These are basically two of the worst NoSQL and SQL implementations in existence.

Recommendation: Stop following all the hype and what all the other blind sheep are doing.

Regarding filesystems... yes they do. Tons of information out there about filesystems you just have to look for it. Read up about ZFS, ReFS and that should get you started.

Re: The genius and folly of MongoDB

#225

Post by nbevans »

danpalmer wrote: post #87
bkanber wrote: post #84

I posted this further down the thread, but I thought I'd share my thoughts on why I like mongo. Most people don't like mongo because 10gen gives the impression that mongo is better than it actually is, many people feel that mongo is not reliable enough for at-scale applications. They're right; it's not. But that's ok, because: Mongo's really great for rapid prototyping. You don't need to worry about updating the sche…

The case for using it as a prototyping database is the best use-case I've seen for Mongo, however I'm not sure it's always a good idea. For a hack-weekend sort of project, fine, but if you are in any way attempting to make a product, it strikes me as the sort of thing that would be really difficult to change later down the line, and so worth investing the very little extra effort it takes to include your schema in th…

The problem with that argument is that prototyping rarely needs a database. Just store stuff in memory. Who the fk in the real world is seriously writing data-layer code for a prototype?

Re: The genius and folly of MongoDB

#226

Post by nbevans »

fiatmoney wrote: post #5
bithive123 wrote: post #4

This article doesn't really make a case for "genius" -- "saving grace", maybe. And in what universe are the Redis data structures "crazy"?

Redis internal data structures are quite sophisticated.

If you consider sets and trees from CompSci 101 to be "quite sophisticated".

Re: The genius and folly of MongoDB

#227

Post by AlisdairO »

mdellabitta wrote: post #133
AlisdairO wrote: post #72

Earlier quoted context omitted.

I believe that InnoDB is an MVCC implementation, so readers blocking writes shouldn't happen. Another thing to add to your list is missing window functions. I'm not a big MySQL fan at all, but it's still leaps and bounds ahead of mongo technologically.

Just ran into this link, which seems to describe how MVCC can sometimes not be enough. http://ronaldbradford.com/blog/understanding-innodb-mvcc-200...

Having read through it, I rather suspect that that's not a matter of writers blocking readers or the other way round, but instead a case of writers blocking writers - he's writing a lot of data to the table, and it's highly likely that InnoDB has escalated the lock to a table lock - which effectively prevents concurrent writes.

Re: The genius and folly of MongoDB

#228

Post by AlisdairO »

yxhuvud wrote: post #105
AlisdairO wrote: post #72

Earlier quoted context omitted.

I believe that InnoDB is an MVCC implementation, so readers blocking writes shouldn't happen. Another thing to add to your list is missing window functions. I'm not a big MySQL fan at all, but it's still leaps and bounds ahead of mongo technologically.

Readers blocking writes may have been changed in a never version than what we use, but it still exist in at least some versions of 5.x.

My apologies - you're right. In the general case readers don't block writes, but InnoDB does use share locks on some foreign key interactions and when using the SERIALIZABLE isolation level.

Re: The genius and folly of MongoDB

#229

Post by dijit »

taspeotis wrote: post #174
functional_test wrote: post #126

Earlier quoted context omitted.

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?

> I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level ... Surely it would be necessary to read the documentation I don't have much sympathy for people who can't RTFM but storing data is kind of a thing for databases.

the word "Database" brings forth images of ACID compliance.

if you're not trying for that standard at all, it's false advertising.

Re: The genius and folly of MongoDB

#230

Post by weddpros »

rogerbinns wrote: post #14

There are also people using MongoDB and finding it meets their needs well, and don't feel the need to keep writing about how everything sucks or is wonderful. (I'm one of them.) None of how MongoDB works is a secret. And just like everything else it has sweet spots and problem areas. And like many others, development continues and it gets better. The database does not get the job done - it is a tool to help get the j…

Most people here seem to complain that their champion lost a benchmark, or that Mongodb does not follow their ideology.

I've used Mongodb for the last 18 months, never lost any data, and it made it obvious that "enough durability" is sometimes... enough. When I switched to MongoDB from MySQL, performance rose 10+ times and I switched from "don't hit the db too much" to "give it more work, 'cause it's idle".

I know it's an ideology problem: otherwise, I can't see why people would complain about a tool they don't use.

Post reply on HN