Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Was MongoDB Ever the Right Choice?

simplethread.com

Post reply on HN
Print view View original

61–70 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#61

Post by TimFogarty »

bonesss wrote: post #53
jandrewrogers wrote: post #50

My anecdote: several years back I had a test lab for measuring the performance and scalability characteristics of various geospatial databases. We added MongoDB to the mix a couple years after they released geospatial support. We always verified basic correctness with a new database by inserting several billion geometries as fast as the database would accept them, reading the entire data set back out, and comparing i…

I evaluated several distributed databases for a healthcare-related system. The ability to lose messages in sharding scenarios, and the specifics of how one would recover them, made me think I could never support MongoDB for anything more serious than Reddit.

The Jepsen tests [1] have been run against MongoDB - while older versions presented edge-case opportunities for data loss, that's no longer the case with recent versions. The Jepsen tests also specifically test sharded clusters. From Aphyr's report:

> MongoDB 3.6.4’s sharded clusters offer comparable safety to non-sharded deployments.

These tests are now integrated into MongoDB's regular test suite. Maybe MongoDB wasn't the right choice for you at the time you were evaluating it, but I just want to point out that MongoDB has matured and improved a great deal.

(Disclaimer: I work for MongoDB)

[1] https://jepsen.io/analyses/mongodb-3-6-4

Re: Was MongoDB Ever the Right Choice?

#62

Post by matwood »

a13n wrote: post #52

These "caveats" are mostly false, or outdated. > Loss of transactions MongoDB 4.0 supports ACID transactions: https://www.mongodb.com/transactions > Loss of relational integrity (foreign keys) > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. I've never seen anyone use MongoDB without also using something like Mongoose where you get all…

The problem with thinking a library like Mongoose satisfies those constraints is that it only works with a single application. Every database I've worked with that made it beyond a prototype outlived the original application. So you either end up building an RDBMS app/api in front of mongo for every new application to use or you have to translate those constraints to every client.

I'm of the opinion to let the "awesome, heavily-used, heavily-tested" RDBMSs built to manage data and constraints do just that.

Re: Was MongoDB Ever the Right Choice?

#63

Post by scarface74 »

dijit wrote: post #17

Since everyone is sharing their opinion and experience with mongodb I think I’ll share mine. As an appeal to authority I would like to mention that I have relevant vocational qualifications on the subject (more geared towards scalability and operations). Although I don’t believe it really matters - it will to those who assume I don’t understand best practice. MongoDB itself is not /really/ a valid choice in many scen…

I’m a big fan of Mongo for the use case you described - searching by ID and all information in one document.

But people don’t seem to understand that there are plenty of scenarios where you really either don’t know the schemes in advance and/or the “schema” is defined by an external source.

I worked for a company that sold software that allowed users to create forms that could be filled out either on the web or via a mobile app.

The user created the form and the schema and the indexes were created on the fly - one collection per type of form. What would an RDMS have bought us?

Re: Was MongoDB Ever the Right Choice?

#64

Post by [deleted] »

jstimpfle wrote: post #38
giornogiovanna wrote: post #28

Earlier quoted context omitted.

Sorry for my ignorance, but what JSON craze?

As a serialization format, JSON is horrible. Way too loose regarding formatting and way too much noise. All that is typically needed is a standard text format for relational data. I.e. a fixed CSV. The only "advantage" to JSON is that it maps directly to the object trees most developers use in their scripted programs (which is misguided IMHO).

[deleted]

Re: Was MongoDB Ever the Right Choice?

#65

Post by jetheredge »

a13n wrote: post #52

These "caveats" are mostly false, or outdated. > Loss of transactions MongoDB 4.0 supports ACID transactions: https://www.mongodb.com/transactions > Loss of relational integrity (foreign keys) > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. I've never seen anyone use MongoDB without also using something like Mongoose where you get all…

This post isn’t about a single snapshot in time, this is about all of the people who didn’t evaluate MongoDB properly over the years and then were “burned” by it. I actually think it has received a bad rap due to people over the years not evaluating it properly. Sure, some of these things have changed (transactions very recently), but they all come with serious caveats and limitations that need to be explored... which was the main point of the article.

Re: Was MongoDB Ever the Right Choice?

#66

Post by scarface74 »

mruts wrote: post #15
sonnyblarney wrote: post #10

I actually think NoSQL might be better for MVP and prototyping. Why? Because they can handle churn more quickly, and you don't have to worry about scale. Once the data layer starts to resonate around a solution ... then pick the right horse for it.

Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.

In that case, I would loose the tooling around Mongo for supporting JSON docs - especially the C# Mongo LINQ driver.

Re: Was MongoDB Ever the Right Choice?

#67

Post by k__ »

rwmj wrote: post #43
matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

I once worked for a company where Lotus Notes fulfilled a similar role (this was back in the late 1990s). Eventually they ran an entire free to sign up web-based email system using 4 giant Notes instances. It was an absolute nightmare, but probably the company would never have happened otherwise because Notes was all that the founders knew. My job was managing the migration off to a normal SQL database, which took th…

I worked in such a company too.

Every time we wanted to do something new a founder would say "Domino can do this!" and then they would spend the whole weekend setting it up for what we were trying to do.

All because we were some kind of IBM partner and they wanted to please the big wigs.

Re: Was MongoDB Ever the Right Choice?

#68

Post by scarface74 »

ants_a wrote: post #56
ddebernardy wrote: post #33

Earlier quoted context omitted.

Nothing on paper, if you get the schema more or less correctly the first time. The problem is when you need to do a schema change that affects terabytes of data down the road.

That is going to be a problem regardless of technology. With an enforced schema you will at least know that all of the existing data matches the schema. Without it you have to hope that you had zero bugs while collecting the terabytes of data.

With almost any language, you can enforce schema via the “ORM”. Yes I know it’s not really an ORM but you get the point.

Re: Was MongoDB Ever the Right Choice?

#69

Post by jacques_chester »

leejo wrote: post #48
kevingadd wrote: post #42

Earlier quoted context omitted.

I'm not clear on why the datastore needed to be schemaless though? It sounds like the schema for the transaction data was well understood and only the blocking requirements were not, but the blocking requirements were formulas/assertions over the well-formed data.

The transaction data was well understood, but did change over time. It was well normalised in a relational backend that was (at the time) a few hundred GB, but it did not have any partitioning. The problem we were trying to solve was that allowing, essentially, arbitrary queries against the main database had the potential to cause problems because we would have to ensure that those queries were optimal and all the re…

What I'm hearing is that you used MongoDB as a read cache, rather than as a database per se.
Post reply on HN