5 ms·

This is off topic, and I might get downvoted, but I realized I am teed up waiting for the "mongoDB hate" comments to role in... seems to be not a lot of love on

This is off topic, and I might get downvoted, but I realized I am teed up waiting for the "mongoDB hate" comments to role in... seems to be not a lot of love on HN for MongoDB. I wonder what positive use cases people have used Mongo for? I've used it for a few small/medium sized projects without problem myself.

bunderbunder 8y ago
Speaking as a sideliner: MongoDB seems to have experienced a rather exaggerated version of the hype cycle. But it also seems like, at this point, the technology is well into the "slope of enlightenment" phase of its hype cycle, and may even have reached the "plateau of productivity". A lot of that is fueled by MongoDB's own efforts - they took the complaints about reliability quite seriously. Case in point: This series of Jepsen tests that they've been funding.
- kitpatella 8y ago
  Hey this is the author. Yes, it cannot be understated that MongoDB solicited work directly to check their sharding system and their new CC feature and were helpful towards getting the work done.
0xFACEFEED 8y ago
The dislike for mongodb usually came from people who were responsible for maintaining medium-large scale deployments of its earlier versions. IMO it all boils down to startup culture and growth; that these goals are incompatible with building a database system responsibly. It broke trust with a lot of people and never really regained it back. Not that it mattered much in the long run. The lesson is that you can get your hands dirty while growing. If you don't grow you're dead anyway. If you do grow then you can throw money at the trust problem until it's fixed. EDIT: Unless you're in the medical industry :P
deleted 8y ago
[deleted]
dgritsko 8y ago
Compare this Jepsen analysis with that of MongoDB 2.4.3 from 2013[1] and you'll see that MongoDB has come a long, long way in the last few years. Note that the linked report on 3.6.4 was actually funded by MongoDB. I think a lot of the hate in the past was caused by their marketing writing checks that the technology couldn't cash. I think that has changed somewhat, but I'm not sure whether popular opinion has come around. 1: https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb
- addicted 8y ago
  I agree. Their marketing was way ahead of their technology and that caught up to them. That being said, they’ve been rapidly improving the tech and it’s looking like a really solid option now.
  - BenoitP 8y ago
    That's still in the limited uses that not having proper SQL semantics allows. I've had to deal with a key-valued-json database on another technology. Lots of different json shapes, even when they are supposed to represent the same concept. Every new feature bringing its own tweak. Low performance, as ad hoc materialized scans + hash joins had to have been developed in the app. I hated every second of it. In the end, I came away with the following exhortation for people tempted to eat the easiness of MongoDB-likes: The world is not a tree. It is a graph. Each entity in the database exists in real life, and interacts with others freely each in a specific manner. This is why they cannot be represented as trees (which is what json is). You need a graph, types, constraint checks, and acid semantics; and boring postgres tables + SQL will provide that. Sure trees are a great way to represent and transport a piece of state. It is self-contained and succinct. This is why I'm a big advocate of GraphQL on top of an RDBMS. Out of the graph of properly stored entities, you can extract the tree that is relevant for the app view you're working with.
    - hinkley 8y ago
      > The world is not a tree. It is a graph. What's your opinion of ember and its sideloading semantics for JSON? I found it interesting... until I had to write my own REST endpoints. I found that none of the database tools I had available were up to doing it. Having to write all those sideloads by hand ended up being too tedious for a non-paying gig and I dropped the experiment.
wenc 8y ago
Mongo works well as a straight-up JSON store for store-and-retrieve use cases (with no analytics). It is horizontally scalable, avoids the overhead of relational databases, has indexing capabilities, and provides a strong consistency model. The big improvement came with WiredTiger, which addressed many of the issues that plagued earlier versions of Mongo. I've seen high-speed machine data stored in Mongo for logging and visualization purposes. It's an improvement over writing csv files to disk. However, if you ever need to perform non-trivial analytics, Mongo's weaknesses quickly become obvious. For machine learning, typically you would want to first ETL the data into a dataframe-like structure (which is a structure native to SQL databases).
- threeseed 8y ago
  Actually MongoDB is quite popular in the analytics space. It has a unique trick with Spark/Hadoop where its data gets represented as a single wide table. This allows you to use it as an analytical/ML feature store which is not possible with anything other than Cassandra. Also not sure where you get the idea dataframes are unique to SQL databases because that's completely wrong. HBase and Cassandra were even the original big data databases and they aren't relational. And Spark can manifest almost any database as a dataframe.
  - nevi-me 8y ago
    I've had lots of fun using Mongo with Spark, I have found it pleasant, though most Spark libraries are good to use, including the JDBC ones. I haven't had much luck with the kind of viz where you don't first do ETL from Mongo to some tabular format.
  - wenc 8y ago
    > not sure where you get the idea dataframes are unique to SQL databases I'm not sure I said this. > HBase and Cassandra were even the original big data databases and they aren't relational. They also had trouble doing joins and many other query operations which are common in analytics. Presto addresses this somewhat. > And Spark can manifest almost any database as a dataframe. Which entails a translation layer from whatever non-tabular form that data was (e.g. JSON) into a dataframe-like structure, rather keeping it in its native form, which reinforces my point. You still need to somehow transform data into tabular form. (ETL is just a batch way of doing this transformation; you can have live transformations of course, with accompanying overheads) BI tools also generally require data to be in tabular form, which entails the use of a translation layer. The Mongo BI connector is one such translator. > Actually MongoDB is quite popular in the analytics space. I work in this space, interact regularly with vendors, and monitor the space actively for strategic developments. This does not track with my observations.
madeuptempacct 8y ago
db.webhooks.find({ "events": { $exists: true, $ne: [], $elemMatch: { "links.cancelInvoice": {$exists: true}} } }) What is this, I don't even. Mongo is a huge pain when it comes to searching nested arrays. And above is just an array in an object, not multiple levels of nesting. I have to re-learn the syntax every time I pick it up. Other than that, it worked great for allowing users to build completely custom forms.
- yoklov 8y ago
  Honestly that doesn't look that bad. SQL is a lot weirder in many ways, and I say that as someone who has written a lot of SQL.
  - zongitsrinzler 8y ago
    I have to agree. Basic search and replace queries are very readable in Mongo and very easily constructable. Imo the advantage of SQL queries shows the best when having to do complex aggregation in Mongo.
- qaq 8y ago
  That was actually a very smart decision as sql parsers are actually hard to write so they saved a ton of dev time.
  - dominotw 8y ago
    There are couple of apache projects like calcite that are being used of new db companies like mapd.
    - qaq 8y ago
      Calcite looks like a really useful project
    - zzzcpan 8y ago
      It's not really a big deal either way. If you have some experience with parsers/compilers, SQL parsers are pretty trivial. If you don't, there is one in SQLite.
manigandham 8y ago
MongoDB was a subpar product that rode the "nosql" document-store hype, but people following hype don't know about technical quality and this lead to it being used in a lot of places where it shouldn't, with marketing plastering over all the downsides. They've slowly made it better and now it's a rather smooth experience but overturning a poor reputation is extremely hard. Meanwhile other database systems have further developed and the need for a pure document-store with weak aggregation and not much else just isn't very enticing. It's still good for data where schema is on-read or in your application, and needs completely flexibility like document and media management, low-volume logging, user profiles and sessions, etc.
amenod 8y ago
I have used it for a monitoring solution that we developed in-house and rented to outside customers. In retrospect we could have used PostgreSQL too, and would have easier time. Hacing someone enforce schema on us wouldn't hurt either. But apart from a few gotchas (like not releasing storage on deletes - this should be fixed now) it worked quite well, so I am not in the hate camp (as opposed to HBase). I did however learn to appreciate strictness of SQL and would need very strong reasons to pick anything else than relational DB for future projects.
jedberg 8y ago
I will personally never use MongoDB because when they first started their philosophy was speed over durability, which is a bad look for a database. Even though they have apparently fixed those problems, it will take them a long time to win that trust back. Also so far Elasticsearch seems to solve all my document storage problems.
- dominotw 8y ago
  > Also so far Elasticsearch seems to solve all my document storage problems. Do you miss joins?
  - jedberg 8y ago
    Not really, but that's because I've been using "nosql" so long that I've gotten used to writing joins in my apps. But that is a fair point, things would be easier with joins. Usually when I need joins I use Postgres though.
- jbergens 8y ago
  As far as I can remember the Elasticsearch test that Jespen made years ago showed at by that time it was a very, very bad db. It was good for indexing content but not for storage.
aikah 8y ago
MongoDB inc itself published bullshit benchmarks claiming they were faster than the competition, omitting the fact that DB writes could fail without returning an error to the client. It seriously damaged their reputation. It also advertised as a replacement for RDBMS which it never was. You'll notice that no other NoSQL store has these reputation issues, no matter how bad they are, it's solely the fault of MongoDB inc and their questionable marketing.
hinkley 8y ago
Do you ever make fun of people for getting fooled twice? The haters that have lasted this long have been fooled once and very painfully. You don't forgive someone technical for straight up lying to you and your peers. For years. That's vendetta territory.

bunderbunder 8y ago

Speaking as a sideliner: MongoDB seems to have experienced a rather exaggerated version of the hype cycle. But it also seems like, at this point, the technology is well into the "slope of enlightenment" phase of its hype cycle, and may even have reached the "plateau of productivity". A lot of that is fueled by MongoDB's own efforts - they took the complaints about reliability quite seriously. Case in point: This series of Jepsen tests that they've been funding.

kitpatella 8y ago
Hey this is the author. Yes, it cannot be understated that MongoDB solicited work directly to check their sharding system and their new CC feature and were helpful towards getting the work done.

0xFACEFEED 8y ago

The dislike for mongodb usually came from people who were responsible for maintaining medium-large scale deployments of its earlier versions. IMO it all boils down to startup culture and growth; that these goals are incompatible with building a database system responsibly. It broke trust with a lot of people and never really regained it back. Not that it mattered much in the long run. The lesson is that you can get your hands dirty while growing. If you don't grow you're dead anyway. If you do grow then you can throw money at the trust problem until it's fixed. EDIT: Unless you're in the medical industry :P

deleted 8y ago

[deleted]

dgritsko 8y ago

Compare this Jepsen analysis with that of MongoDB 2.4.3 from 2013[1] and you'll see that MongoDB has come a long, long way in the last few years. Note that the linked report on 3.6.4 was actually funded by MongoDB. I think a lot of the hate in the past was caused by their marketing writing checks that the technology couldn't cash. I think that has changed somewhat, but I'm not sure whether popular opinion has come around. 1: https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb

addicted 8y ago
I agree. Their marketing was way ahead of their technology and that caught up to them. That being said, they’ve been rapidly improving the tech and it’s looking like a really solid option now.
- BenoitP 8y ago
  That's still in the limited uses that not having proper SQL semantics allows. I've had to deal with a key-valued-json database on another technology. Lots of different json shapes, even when they are supposed to represent the same concept. Every new feature bringing its own tweak. Low performance, as ad hoc materialized scans + hash joins had to have been developed in the app. I hated every second of it. In the end, I came away with the following exhortation for people tempted to eat the easiness of MongoDB-likes: The world is not a tree. It is a graph. Each entity in the database exists in real life, and interacts with others freely each in a specific manner. This is why they cannot be represented as trees (which is what json is). You need a graph, types, constraint checks, and acid semantics; and boring postgres tables + SQL will provide that. Sure trees are a great way to represent and transport a piece of state. It is self-contained and succinct. This is why I'm a big advocate of GraphQL on top of an RDBMS. Out of the graph of properly stored entities, you can extract the tree that is relevant for the app view you're working with.
  - hinkley 8y ago
    > The world is not a tree. It is a graph. What's your opinion of ember and its sideloading semantics for JSON? I found it interesting... until I had to write my own REST endpoints. I found that none of the database tools I had available were up to doing it. Having to write all those sideloads by hand ended up being too tedious for a non-paying gig and I dropped the experiment.

wenc 8y ago

Mongo works well as a straight-up JSON store for store-and-retrieve use cases (with no analytics). It is horizontally scalable, avoids the overhead of relational databases, has indexing capabilities, and provides a strong consistency model. The big improvement came with WiredTiger, which addressed many of the issues that plagued earlier versions of Mongo. I've seen high-speed machine data stored in Mongo for logging and visualization purposes. It's an improvement over writing csv files to disk. However, if you ever need to perform non-trivial analytics, Mongo's weaknesses quickly become obvious. For machine learning, typically you would want to first ETL the data into a dataframe-like structure (which is a structure native to SQL databases).

threeseed 8y ago
Actually MongoDB is quite popular in the analytics space. It has a unique trick with Spark/Hadoop where its data gets represented as a single wide table. This allows you to use it as an analytical/ML feature store which is not possible with anything other than Cassandra. Also not sure where you get the idea dataframes are unique to SQL databases because that's completely wrong. HBase and Cassandra were even the original big data databases and they aren't relational. And Spark can manifest almost any database as a dataframe.
- nevi-me 8y ago
  I've had lots of fun using Mongo with Spark, I have found it pleasant, though most Spark libraries are good to use, including the JDBC ones. I haven't had much luck with the kind of viz where you don't first do ETL from Mongo to some tabular format.
- wenc 8y ago
  > not sure where you get the idea dataframes are unique to SQL databases I'm not sure I said this. > HBase and Cassandra were even the original big data databases and they aren't relational. They also had trouble doing joins and many other query operations which are common in analytics. Presto addresses this somewhat. > And Spark can manifest almost any database as a dataframe. Which entails a translation layer from whatever non-tabular form that data was (e.g. JSON) into a dataframe-like structure, rather keeping it in its native form, which reinforces my point. You still need to somehow transform data into tabular form. (ETL is just a batch way of doing this transformation; you can have live transformations of course, with accompanying overheads) BI tools also generally require data to be in tabular form, which entails the use of a translation layer. The Mongo BI connector is one such translator. > Actually MongoDB is quite popular in the analytics space. I work in this space, interact regularly with vendors, and monitor the space actively for strategic developments. This does not track with my observations.

madeuptempacct 8y ago

db.webhooks.find({ "events": { $exists: true, $ne: [], $elemMatch: { "links.cancelInvoice": {$exists: true}} } }) What is this, I don't even. Mongo is a huge pain when it comes to searching nested arrays. And above is just an array in an object, not multiple levels of nesting. I have to re-learn the syntax every time I pick it up. Other than that, it worked great for allowing users to build completely custom forms.

yoklov 8y ago
Honestly that doesn't look that bad. SQL is a lot weirder in many ways, and I say that as someone who has written a lot of SQL.
- zongitsrinzler 8y ago
  I have to agree. Basic search and replace queries are very readable in Mongo and very easily constructable. Imo the advantage of SQL queries shows the best when having to do complex aggregation in Mongo.
qaq 8y ago
That was actually a very smart decision as sql parsers are actually hard to write so they saved a ton of dev time.
- dominotw 8y ago
  There are couple of apache projects like calcite that are being used of new db companies like mapd.
  - qaq 8y ago
    Calcite looks like a really useful project
  - zzzcpan 8y ago
    It's not really a big deal either way. If you have some experience with parsers/compilers, SQL parsers are pretty trivial. If you don't, there is one in SQLite.

manigandham 8y ago

MongoDB was a subpar product that rode the "nosql" document-store hype, but people following hype don't know about technical quality and this lead to it being used in a lot of places where it shouldn't, with marketing plastering over all the downsides. They've slowly made it better and now it's a rather smooth experience but overturning a poor reputation is extremely hard. Meanwhile other database systems have further developed and the need for a pure document-store with weak aggregation and not much else just isn't very enticing. It's still good for data where schema is on-read or in your application, and needs completely flexibility like document and media management, low-volume logging, user profiles and sessions, etc.

amenod 8y ago

I have used it for a monitoring solution that we developed in-house and rented to outside customers. In retrospect we could have used PostgreSQL too, and would have easier time. Hacing someone enforce schema on us wouldn't hurt either. But apart from a few gotchas (like not releasing storage on deletes - this should be fixed now) it worked quite well, so I am not in the hate camp (as opposed to HBase). I did however learn to appreciate strictness of SQL and would need very strong reasons to pick anything else than relational DB for future projects.

jedberg 8y ago

I will personally never use MongoDB because when they first started their philosophy was speed over durability, which is a bad look for a database. Even though they have apparently fixed those problems, it will take them a long time to win that trust back. Also so far Elasticsearch seems to solve all my document storage problems.

dominotw 8y ago
> Also so far Elasticsearch seems to solve all my document storage problems. Do you miss joins?
- jedberg 8y ago
  Not really, but that's because I've been using "nosql" so long that I've gotten used to writing joins in my apps. But that is a fair point, things would be easier with joins. Usually when I need joins I use Postgres though.
jbergens 8y ago
As far as I can remember the Elasticsearch test that Jespen made years ago showed at by that time it was a very, very bad db. It was good for indexing content but not for storage.

aikah 8y ago

MongoDB inc itself published bullshit benchmarks claiming they were faster than the competition, omitting the fact that DB writes could fail without returning an error to the client. It seriously damaged their reputation. It also advertised as a replacement for RDBMS which it never was. You'll notice that no other NoSQL store has these reputation issues, no matter how bad they are, it's solely the fault of MongoDB inc and their questionable marketing.

hinkley 8y ago

Do you ever make fun of people for getting fooled twice? The haters that have lasted this long have been fooled once and very painfully. You don't forgive someone technical for straight up lying to you and your peers. For years. That's vendetta territory.