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

91–100 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#91

Post by scarface74 »

felixfbecker wrote: post #89
scarface74 wrote: post #63

Earlier quoted context omitted.

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…

PostgreSQL's JSON columns are pretty powerful

And the tooling around it? For instance the Mongo C# Linq driver can translate LINQ to MongoQuery.

Re: Was MongoDB Ever the Right Choice?

#92

Post by danpalmer »

TomK32 wrote: post #37

It is still in production as the main database in a startup I joined in 2010 and kicked off their software's development. I've been through smaller ups and downs, but we never lost data. The reason why I loved it back then and still do today (I'm using mongodb in my own little webapp) is the speed of development. The few data migrations that I had to write in over eight years where nothing compared to what you'd have…

It sounds like your product was in the sweet spot where there isn’t much data complexity or evolution, and the schema is understandable and easy enough to modify over time without strictness.

The product I work on has ~400 tables active at the moment, and ~800 that have ever existed in it over the last 6 years. We depend on the database schema to reduce complexity at the application level.

I don’t think the complexity would be manageable at the application level if we couldn’t do this. At least not with the ~6 engineers working on it.

Re: Was MongoDB Ever the Right Choice?

#93

Post by felixfbecker »

a13n wrote: post #85
tjpnz wrote: post #84

While I think MongoDB is deserving of a lot of the criticism it receives I think the bigger issue is with those who adopt it without a full understanding of their data and the use cases they might need to implement. There are countless stories now from people who assumed their data wasn't relational only to discover much later on that the opposite was true. There are cases where a document oriented datastore could be…

There's no reason you can't use MongoDB with relational data. Foreign references? They've got them. https://docs.mongodb.com/manual/reference/database-reference... ACID transactions? They've got them. https://www.mongodb.com/transactions

If relations are embedded in a document then you favour querying from the "side" of the relation that is the outer document. But usually you cannot anticipate from what sides of the relation you may want to query in the future. As such, MongoDB may scale nicely for performance, but it doesn't scale nicely for business needs. A relational database is completely unbiased in that regard, you do not need to make nor encode any decision on what would be the "outer" document or inner nested objects. It's all just entities and relations.

Re: Was MongoDB Ever the Right Choice?

#94

Post by chrisweekly »

reustle wrote: post #7

MongoDB was great to me for prototyping, either manually or with tools like Meteor.

Yeah, Meteor was pretty amazing when it first came out. It felt like it was from several years in the future. As I recall, it relied on mongo on the server and a minimongo that ran in the client. It made it trivially easy to create universal real-time webapps, which was a game-changer for me at the time. Reactivity has since become mainstream, but at the time it represented a bright line / step function increase in both DX and UX.

Re: Was MongoDB Ever the Right Choice?

#95

Post by 52-6F-62 »

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…

Documents. You said it there.

I work a lot with documents in my current role which includes a lot of JSON structures as well.

MongoDB has been immensely useful for a team with limited scope (and requisitional abilities within the organization) to get up and running and store backups of documents that have been processed and JSON API responses.

I definitely wouldn’t apply it as a panacea, either.

Like any tool, it has it’s place in the belt for me. It’s no universal hammer, though.

Re: Was MongoDB Ever the Right Choice?

#97

Post by SigmundA »

scarface74 wrote: post #91
felixfbecker wrote: post #89

Earlier quoted context omitted.

PostgreSQL's JSON columns are pretty powerful

And the tooling around it? For instance the Mongo C# Linq driver can translate LINQ to MongoQuery.

I haven't used myself but have heard good things: http://jasperfx.github.io/marten/documentation/documents/que...

Re: Was MongoDB Ever the Right Choice?

#98

Post by a13n »

tjpnz wrote: post #88
a13n wrote: post #85

Earlier quoted context omitted.

There's no reason you can't use MongoDB with relational data. Foreign references? They've got them. https://docs.mongodb.com/manual/reference/database-reference... ACID transactions? They've got them. https://www.mongodb.com/transactions

But why wouldn't I just use Postgres instead?

But why wouldn't you just use MongoDB instead?

Re: Was MongoDB Ever the Right Choice?

#99

Post by flurdy »

matwood wrote: post #62
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 "aweso…

True, using a library to hide the limitations of a DB smells bad. It is fixing the problem in the wrong location.

I may have misread your comment but rarely do more than one client application access a database. Especially in today's often Microservices architecture. So using a library as mentioned is fine. And as the app evolves/gets rewritten you can keep the library or replace it with a similar one.

Over 10+ years ago I did join a few projects with existing architecture that had evolved to multiple applications accessing the same database. And they were a nightmare but that is rare to encounter these days as most people have learned that one app = one DB. (Data warehousing is a possible exception, but mostly those datasets are exported instead as well as streams for machine learning).

Probably preaching to the choir but multiple clients mean feature freeze/deadlock, no DB refactoring and spaghetti architecture.

Re: Was MongoDB Ever the Right Choice?

#100

Post by fooker »

scarface74 wrote: post #63
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…

What happens when you need to do something like "Select browser user agent from all users who filled forms for a particular set of clients after a given date." ?

This would fit in a single SQL query which is expected to perform reasonably well, with an unstructured database optimizing this query will take months of work.

Post reply on HN