Live data from Hacker News

The growing irrelevance of MongoDB

itexto.com.br

51–60 of 114 posts

Re: The growing irrelevance of MongoDB

#51
post #47
post #39

Earlier quoted context omitted.

"I don't want to create a schema..." You are always going to end up creating a schema, whether it's explicit in your tables or implicit within your code. Otherwise you end up with completely heterogeneous data which is impossible to query in any useful way. This is a red herring.

Not really. Maybe some products have an attribute that others don't. Maybe you want to query by that attribute. The query won't turn up products without that attribute. Maybe that's ok. Like if you wanted to find all shoes with black laces you can just query for that. Tractors don't even have laces and so they don't come up in the results. In a sql db, every single thing needs to fit into a flat schema with nesting d…

Agreed. That said, optional schema enforcement would be really nice (in my experience, most of the data has a predefined format; so why not define schema and enforce it?).

Re: The growing irrelevance of MongoDB

#52
post #44
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've used it and been happy. If you want something that's simple to use, know your schema partly but not entirely, and you don't mind losing a few writes, then mongo fits. Relational databases place such emphasis on reliability. Mongo is generally reliable but only two or three nines, and it's simple. For example, if you're collecting sub-cent line items for invoices, you might prefer to collect 99.x% of the line ite…

What? When would it ever be OK to lose parts of an invoice. Mongo apologists baffle me sometimes. To anyone considering MongoDB, don't be fooled, you probably want to stick with an RDBMS.

Re: The growing irrelevance of MongoDB

#53
post #43
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…

> Facebook clone Diaspora is a social network that made the mistake of choosing mongodb for their first iteration. Here's a blog post where one of the involved developers explains why it's not good for that, even: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...

To be fair, this is a poor technical choice that no reputable DBA should ever make... Not really the technology's fault.

Re: The growing irrelevance of MongoDB

#55
post #49
post #36

Earlier quoted context omitted.

PostgreSQL has full support for JSON [1]. So, quite easily in fact. [1]: http://www.postgresql.org/docs/9.4/static/datatype-json.html

Thanks, I didn't know that. What's the benefit of using PostgreSQL though if the functionality is the same?

The reliability and speed advantages of PostgreSQL over MongoDB. Plus the fact that sometimes KV/document is better and sometimes normalized relational. Is nice if one tool solves both.

Re: The growing irrelevance of MongoDB

#56
post #49
post #36

Earlier quoted context omitted.

PostgreSQL has full support for JSON [1]. So, quite easily in fact. [1]: http://www.postgresql.org/docs/9.4/static/datatype-json.html

Thanks, I didn't know that. What's the benefit of using PostgreSQL though if the functionality is the same?

Full ACID transactions, reliability, access to trained DBA-s.

Re: The growing irrelevance of MongoDB

#57
post #44
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've used it and been happy. If you want something that's simple to use, know your schema partly but not entirely, and you don't mind losing a few writes, then mongo fits. Relational databases place such emphasis on reliability. Mongo is generally reliable but only two or three nines, and it's simple. For example, if you're collecting sub-cent line items for invoices, you might prefer to collect 99.x% of the line ite…

This is satire, right? Right?…

Re: The growing irrelevance of MongoDB

#58
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 o…

> NoSQL doesn't replace SQL databases, it's looking to optimise a use case where transactions are not required.

I'd be curious to know in what contexts anyone would not want transactions.

I readily see the case for memcached or equivalent when it comes to caching -- it is very valid, and indeed useful, when slightly outdated data is perfectly acceptable. I can even picture how you might be using MongoDB to do the same, even if you admittedly have me wondering how you're invalidating the mess.

For a persistent data store, however, I'm honestly at a loss. In my own experience, transactions are needed as soon as there's a remote possibility that a concurrent write may occur. Even embedded systems need them, when you're threading statements concurrently for performance reasons, or when you're subsequently merging local data with another node. (See CoreData/iCloud bugs for what occurs when you ignore ACID in the latter case.)

Re: The growing irrelevance of MongoDB

#59
post #47
post #39

Earlier quoted context omitted.

"I don't want to create a schema..." You are always going to end up creating a schema, whether it's explicit in your tables or implicit within your code. Otherwise you end up with completely heterogeneous data which is impossible to query in any useful way. This is a red herring.

Not really. Maybe some products have an attribute that others don't. Maybe you want to query by that attribute. The query won't turn up products without that attribute. Maybe that's ok. Like if you wanted to find all shoes with black laces you can just query for that. Tractors don't even have laces and so they don't come up in the results. In a sql db, every single thing needs to fit into a flat schema with nesting d…

Are you saying you're using a single MongoDB collection as a dumping ground for all your entities? I hope you're not building a real product that someone has to maintain.

Re: The growing irrelevance of MongoDB

#60
post #46
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. Can someone suggest when it is actually useful over a properly tuned relational database? Seamless auto-sharding, supported as a first-class use case. Particularly in a cloud environment where you can have your system automatically spin up more hosts as load increases (and take them down as load drops) with zero human intervention…

> but I've yet to see an affordable relational database with out-of-the-box auto-sharding support that comes anywhere close to what mongo offers.

FoundationDB is a bit weird, but it handles automatic scaling-out, and has an ANSI SQL interface (backed onto a K-V store): https://foundationdb.com/key-value-store/white-papers/scalab...

Caveat: I've not used it for more than hobby stuff yet, but it's a fascinating bit of technology!

Post reply on HN