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

71–80 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#71

Post by k__ »

arethuza wrote: post #39
jstimpfle wrote: post #38

Earlier quoted context omitted.

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).

Not sure I would call CSV a "standard text format" - I've seen many many problems over the years with badly formed CSV files and bad Unicode handling. CSV appears to be an "almost standard" where 98% of the time it is fine and the remaining 2% are an utter nightmare.

Haha, yes I remember building my first HTTP-API in 2010.

It had to deliver three kinds of formats: CSV, JSON, and XML.

JSON was a one-liner, then came CSV and then XML.

But all the consultants working in customer projects said CSV was the most important one because it's industry standard.

When the consultants sent me example CSV files from like 5 customers I couldn't believe they all had a different format.

Re: Was MongoDB Ever the Right Choice?

#72

Post by a13n »

jetheredge wrote: post #65
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... whic…

Hey Justin, thanks for writing the article! I agree with you that there was a failure of evaluation, and that MongoDB has matured quite a bit since the NoSQL explosion.

Sorry if my comment came across as a criticism of your post. It was more targeted at the long threads of people bashing MongoDB, thinking the caveats are still relevant/accurate today. Because they really aren't – MongoDB is a completely valid choice of database today.

ACID transactions were added over a year ago, and Mongoose is almost as old as MongoDB itself.

Re: Was MongoDB Ever the Right Choice?

#73

Post by jacques_chester »

mattparlane wrote: post #8

I'm still in charge of a production system serving around 2,000 small to medium websites from a 2-machine MongoDB cluster. It's been running on MongoDB since around 2010 and we have NEVER had any issues. I accept that the unacknowledged writes was a bad decision, but IMHO if you deploy a new database without reading the documentation, you have bigger issues. The reality is that there are some places where speed of mo…

1. Writing DDL is not hard. It's just not very hard.

2. You can go from strict guarantees to looseness safely, when you demonstrably need to. The reverse isn't true -- it's easy to wind up realising, much too late, that you actually needed particular guarantees that you didn't even think of.

Relational databases didn't become incredibly popular by accident. It's because they were a drastic improvement -- theoretically and empirically -- on the generation of NoSQL databases that preceded them.

Re: Was MongoDB Ever the Right Choice?

#74

Post by ddebernardy »

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.

Yeah, but it's a different type of problem.

If you've a schema, you sometimes need to rewrite an entire table as part of a migration, and that can mean heavy engineering if you want to avoid downtime or disabling writes during the migration. There are 1:1 relationships between tables in the wild that wouldn't have passed a sniff test as part of an early schema design review, but then got created regardless to avoid a lengthy table rewrite.

If you've no schema proper, by contrast, you can manage multiple variations of what the data might look like in code. Not that such a thing is simple; it's definitely not, for the reason you raised. But it's simpler to deploy and migrate, or certainly might appear to be so to someone who isn't comfortable with SQL.

Also, there's a class of apps where having a schema doesn't add much value and NoSQL actually makes sense. Think storing and mining logs, scraped data, ML training sets, etc. -- apps where it doesn't matter much however a big pile of data gets stored, so long as you can shovel through it in parallel or store it very fast.

Re: Was MongoDB Ever the Right Choice?

#75

Post by acl777 »

If one researches the company's history, MongoDB came from a specific need the founders had for another product: ShopWiki.

ShopWiki is a shopping price listing site, where it keeps tracks of prices for any item: computer, clothing, food, etc. ShopWiki needs to be able to store, access, AND search amongst all of these different items. So, MongoDB is the perfect solution.

If the application being built has similar requirements to ShopWiki or a retail site where it sells _everything_, then MongoDB IS the right choice, because the founders basically built MongoDB for ShopWiki.

To sum it up: Is MongoDB the right choice? If the product is similar to ShopWiki, then yes.

Re: Was MongoDB Ever the Right Choice?

#76

Post by jacques_chester »

taffer wrote: post #51
myrryr wrote: post #36

Earlier quoted context omitted.

Because you still have to write a layer between your web app and the database at the prototyping stage? I can't just make calls from Html + JS to Postgres. But I can with MongoDB

Or you can use something like Postgrest: http://postgrest.org

Or Hasura GraphQL Engine: https://github.com/hasura/graphql-engine

Re: Was MongoDB Ever the Right Choice?

#77

Post by [deleted] »

acl777 wrote: post #75

If one researches the company's history, MongoDB came from a specific need the founders had for another product: ShopWiki. ShopWiki is a shopping price listing site, where it keeps tracks of prices for any item: computer, clothing, food, etc. ShopWiki needs to be able to store, access, AND search amongst all of these different items. So, MongoDB is the perfect solution. If the application being built has similar requ…

[deleted]

Re: Was MongoDB Ever the Right Choice?

#78

Post by bluedino »

k__ wrote: post #67
rwmj wrote: post #43

Earlier quoted context omitted.

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.

This happened from 2000-2010 but with Sharepoint.

Re: Was MongoDB Ever the Right Choice?

#79

Post by mcintyre1994 »

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…

> Can you give an example of something that you realistically would want to do in SQL that you can't with a JSON query?

Can you define joins in terms of each other? Otherwise, any join that isn't left outer join ($lookup) can't be represented in an aggregate query AFAIK.

Re: Was MongoDB Ever the Right Choice?

#80

Post by teh_klev »

k__ wrote: post #67
rwmj wrote: post #43

Earlier quoted context omitted.

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.

Once upon a time in a job far away, about 15% of my time was allocated to being the company sysadmin, and as all good sysadmins do, reduced that time to about 5%.....until....

One day, and despite my protests, I had to bin our perfectly fine and well maintained/loved Exchange server for fricken Notes/Domino just because one of the investors had some free licenses. After the migration, everyone hated it and I was persona non grata seeing as it was me who had to switch us over. It never worked properly. I left not long afterwards and the poor sod who was my replacement had the joy of looking after that dumpster fire.

edit: opening sentence

Post reply on HN