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.
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
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.
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.
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.
They acquired WiredTiger in 2014 and MongoDB has never looked back since. Sure there is a lot of hate on HN but they are doing very well out in the real world. And actually it's a pretty good database if your domain model fits.
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.
Do you miss joins?
But that is a fair point, things would be easier with joins. Usually when I need joins I use Postgres though.
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.
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).
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.
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.
It's an improvement over writing csv files to disk.
I'm curious: how so?
memcached and Redis are commonly deployed for caching, but not for persistence (Redis has optional persistence). That is not to say you can't use them, but I'm not sure what makes them a necessarily better choice than Mongo in this situation (persisted high-speed machine data).
Edit: OK, I see you mean the "for store-and-retrieve use cases" part. You have a point, though Mongo seems to be ok for that use case too.
It tends not to occur to me that durability is a feature people are looking for in nosql, but if you’re trying to avoid having three to five copies (SQL, nosql, search, reporting, ?). of your data I could understand. But as the team gets bigger it gets harder to maintain that, figuratively and literally.
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.
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.