Startup Engineers and Our Mistakes with MongoDB

These "Why technology X is worthless" types of posts and statements always give me a bit of a laugh. As with most technologies, there is a) a learning curve, and b) best practices to follow.

Many of the comments here seem to discuss a few things which, in my opinion, lead me to believe that the implementation is incorrect or decisions are being made on old data or based on older versions of MongoDB. Making arguments against any product based on previous versions seems to be counter productive. Most of the posts here don't make reference to a specific MongoDB version, but many reference their experience with the product in 2012.

Assuming that these experiences were at the end of 2012 with the most current at the time version, we are still talking about version 2.2.2. The current stable version is 3.4.6. As you can imagine, there have been many advances to the product in five years. Basing one's knowledge and opinion of MongoDB on old versions doesn't seem logical. Even back in 2012 though, there was a lot of misinformation about MongoDB. A blog post from that time period (https://blog.serverdensity.com/does-everyone-hate-mongodb/) argues some of that information at that time.

Many other comments were made based on what seems to be a lack of spending time with learning MongoDB. It is a non-relational document store. It is NOT a relational database. It requires a different way of storage design and thinking and attempting to force MongoDB to be a SQL-like database is silly. SQL is indeed a popular option and can work well.

However, non-relational databases work well too. There are lots of implementations of it across a lot of companies. A few relatively recent posts are good examples https://engineering.snagajob.com/mongodb-in-aws-does-it-real... and https://mongomikeblog.wordpress.com/2016/04/29/why-we-went-w... That doesn't account for many of the large companies out there using it, like Expedia, Facebook, Forbes, to name a few.

If we want to have a discussion about specific, current, features of MongoDB, that's great. There are a lot of them. Many have been mentioned. Some have been mentioned as a negative due to what appears to be poor implementation. If we want to debate pros and cons of any product, we should be sure that we are talking about how things are intended to be implemented and not some hacked together approach.

Perhaps the marketing spin was too aggressive. I'm not a marketing person. I'll leave it to Mr. Horowitz to backup his claims. But if we are going to have a discussion about the pros and cons of MongoDB, can we at least agree to not talk about old versions? I mean, I had a bad experience with Windows 3.1, so should I not use Windows anymore? ;-)

From your scenarios and what your asking to get from your data (yes I understand your problem domain, I wrote mobile software for field service workers in a previous life), you're not doing a lot of complex two way joins where you need to get all of the data from table A and match it to all of the data from table B. You're starting with a known entity like a terminal with references to other known entities. In your scenarios all your DB is doing is searching tables based on indexes and creating a data set in memory. If you did the same searches one table at a time starting from your known root - the terminal you are looking for and query individual tables based on foreign references, the only performance difference would be the slight overhead of multiple DB calls. You wouldn't even be getting unnecessary data back.

Even if I were using a relational database, I would still separate out my different domains (drivers, terminals, stops, etc.) into different classes/microservices and join the different entities in memory.

This would allow different developers, teams etc. to focus on separate business objects and would allow you to start off with a monolithic code base/app and separate the app out to microservice later without intertwined logic and to mix and match storage based on what makes sense.

I never said always embed everything into one document. I said think through your aggregate roots to decide how to design your apps and your document model.

I've designed this way for the last 10 years - 9 using RDMSs. I don't do complex 10 way joins for apps. I separate out business domain logically and let each module be responsible for its own domain and then have an overarching orchestrating class that combines the various objects when needed.

Scale and also the data structure is often times very flat; usually just a bunch of records from sensor readings.

Key-value stores provide very little. The whole deal with SQL/relational databases, is that they provide much much more. The SQL database like CockroachDB are built on top of RocksDB, a key-value database: https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mappin...

It's the difference between assembly language and a high-level language. Key-value stores are simple, basic, and primitive. What's wrong with that? It's like a farmer saying, I don't want to learn how to use a tractor (it's too complicated), and who chooses to farm with a hand tools instead.

> if you use tools you don't understand

Yea.... key-value stores are incredibly complex and require years of learning to understand.

I could explain a key-value store to a five-year old. In fact, I think even a pigeon can understand the fundamental principle underlying a key-value store. https://en.wikipedia.org/wiki/Pigeon_intelligence

For any non-trivial data model, go with something that can capture your model at a high level, like a relational database or a graph database.