Live data from Hacker News

The growing irrelevance of MongoDB

itexto.com.br

21–30 of 114 posts

Re: The growing irrelevance of MongoDB

#21
post #15

Earlier quoted context omitted.

Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain…

Care to elaborate? Beside maybe for the suggestion system, I really don't see what's the gain compared to a relational database.

Probably the EAV nightmare

Re: The growing irrelevance of MongoDB

#22
post #9

I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…

> Can someone suggest when it is actually useful over a properly tuned relational database?

In your own question you kind of hint at it. You need a tuned database. NoSQL lowers the barrier to entry for fast persistent data storage with replication. NoSQL doesn't replace SQL databases, it's looking to optimise a use case where transactions are not required.

Personally I use Mongo a bit like a cache, sitting in front of a SQL DB. Things that need to be ACID are handed back and forth. Those that don't are kept in Mongo and I get the best of both worlds.

Re: The growing irrelevance of MongoDB

#23
post #9

I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…

I'd say a graph database would work much better for building a Facebook clone compared to a document store like MongoDB... And a relational database would still be better than the document store.

I've been using Mongo happily to provide online analytics solutions, but the advantage is mostly from the development side, not really from the performance side.

On the other hand, this kind of approach is great for attribute matching, which is usually a nightmare to do properly with a RDBMS.

Re: The growing irrelevance of MongoDB

#24
post #9

I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…

> I have yet to see a real use case for Mongo unless you are building a Facebook clone

People seem to keep making the mistake of building a social network in mongo. It's entirely unsuitable for that.

Source: I've helped 3 companies move their social networks from MongoDB to OrientDB when they figured out that MongoDB prevents them from shipping features that users expect, e.g. friend-of-a-friend style queries

Re: The growing irrelevance of MongoDB

#25
post #14
post #9

I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…

Lately (and not so lately ;) there has been a lot of bad press about MongoDB. We use it extensively as part of our product (on single servers) and it fills this role nicely. It has a few drawbacks, most notably huge disk space requirements (MongoDB has no compression) which we are hoping to solve with TokuMX (haven't tried it yet). It has some other quirks too, but in general it just... works. And I love using a docu…

The good news is, you can just wait a few weeks and get the possibility to use WiredTiger inside the upcoming 2.8.0. That will solve a few pain points that we've been dragging along for years (namely, document-level locking, disk requirements, multi-document transactions).

Re: The growing irrelevance of MongoDB

#26

Unfortunately I didn't find much information in the article. Basically I got out of it: - he likes JS, and was comfortable with MEAN-stack (MongoDB/Express web framework/AngularJS/Node.js) - he found that for document oriented purposes MongoDB could sometimes be a nice fit - he found that replacing MongoDB with the drop-in replacement TokuMx (seems like a MySQL/MariaDB type of idea), he could get a big performance in…

>I would really like to know when to choose which database

I have asked this question before - under what situations is Mongo not just equally good as Postgres - but actually better?

The only really coherent answer was that it was easier to configure replication (presumably because it chooses a lot of defaults for you). I'm not even sure that was a good thing given the number of obscure bugs that can arise from incorrectly configured replication.

Postgres even seems to be more performant at NoSQL use cases (using the JSON store) than Mongo, which is frankly embarrassing.

Re: The growing irrelevance of MongoDB

#27
post #9

I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…

I just like being able to insert a random JSON into a collection and query it by any of its properties. Not sure how I would do that with a relational database.

Re: The growing irrelevance of MongoDB

#28

Earlier quoted context omitted.

Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain…

So what happens when you want to list all of the products in a category?

Have a category field or link in the table. Join to it. Joins are not evil, they are damn useful. And well done if your product has become large enough to have scaling problems that can't be solved by a bit of indexing on the joins.

Re: The growing irrelevance of MongoDB

#29
post #19
post #14

Earlier quoted context omitted.

Lately (and not so lately ;) there has been a lot of bad press about MongoDB. We use it extensively as part of our product (on single servers) and it fills this role nicely. It has a few drawbacks, most notably huge disk space requirements (MongoDB has no compression) which we are hoping to solve with TokuMX (haven't tried it yet). It has some other quirks too, but in general it just... works. And I love using a docu…

Postgres and MySQL just work as far as I am concerned.

I never said or implied that they don't. What is your point?

Re: The growing irrelevance of MongoDB

#30
post #14

Earlier quoted context omitted.

Lately (and not so lately ;) there has been a lot of bad press about MongoDB. We use it extensively as part of our product (on single servers) and it fills this role nicely. It has a few drawbacks, most notably huge disk space requirements (MongoDB has no compression) which we are hoping to solve with TokuMX (haven't tried it yet). It has some other quirks too, but in general it just... works. And I love using a docu…

The good news is, you can just wait a few weeks and get the possibility to use WiredTiger inside the upcoming 2.8.0. That will solve a few pain points that we've been dragging along for years (namely, document-level locking, disk requirements, multi-document transactions).

And compression
Post reply on HN