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

MongoDB History

quickprogrammingtips.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: MongoDB History

#41

Post by Scarbutt »

xtracto wrote: post #39
conradfr wrote: post #13

Earlier quoted context omitted.

I interviewed recently at a payment provider that is rewriting its PHP/Mysql monolith in Java & go microservices with MongoDb. The architect would praise static typing but would prefer MongoDb "because it's easier to add a column". It felt weird but I've never used MongoDb so I could not really argue about it.

Oh man. Payment provider data in mongo... even if by now MongoDB doesnt lose data... you REALLY want your ledger or OLTP to be in a relational, transactional database.

Stripe started with mongodb https://www.mongodb.com/blog/post/mongodb-powering-the-magic...

Don't know what they use now or if they still use it.

Re: MongoDB History

#42

Post by staysaasy »

numlock86 wrote: post #38
threeseed wrote: post #19

Earlier quoted context omitted.

MongoDB is the fastest and easiest to scale schema-on-read document store. So if your domain model is document orientated e.g. a star schema with dozens of joins, where you don't know the schema upfront or you have polymorphic relationships it is a really useful way to store your data.

Hm, my impression was always that if I have such data I didn't really understand my data yet. What's a concrete prime example for using MongoDB?

That's actually kind of the point – if you're working on a new project whose requirements might change rapidly Mongo can be a really great fit (eg a toy project; a prototype for a new internal service; a hackathon; a pre-traction startup).

Re: MongoDB History

#43

Post by kbyatnal »

xtracto wrote: post #39
conradfr wrote: post #13

Earlier quoted context omitted.

I interviewed recently at a payment provider that is rewriting its PHP/Mysql monolith in Java & go microservices with MongoDb. The architect would praise static typing but would prefer MongoDb "because it's easier to add a column". It felt weird but I've never used MongoDb so I could not really argue about it.

Oh man. Payment provider data in mongo... even if by now MongoDB doesnt lose data... you REALLY want your ledger or OLTP to be in a relational, transactional database.

IIRC Stripe relies heavily on Mongo

Re: MongoDB History

#44

Post by wmf »

threeseed wrote: post #21
wmf wrote: post #11

Earlier quoted context omitted.

The problem of schemas slowing your development.

There is this myth that schemas must be enforced at the database level. But the majority of databases are only accessed by one web app. And in that web app you can enforce that schema in code. In fact in code you have much safer and powerful options e.g. enforcing business rules such as this string field must start with aaa.

In reality people don't do this. When people use schemaless databases, usually they don't even know what their schema is and it gets enforced in an accidental, half-assed way.

Re: MongoDB History

#45

Post by blibble »

threeseed wrote: post #17
slyall wrote: post #8

The "Mongo DB is Web Scale" video just turned 10 years old. I'm pretty sure that was a big factor in MongoDB not being taken seriously by many people. https://www.youtube.com/watch?v=b2F-DItXtZs

Anybody who makes complex technology decisions based on marketing copy doesn't deserve to be taken seriously either. Not that I think these people actually exist other than in the minds of many HN commenters. Oracle on their website right now says "we lead the market in autonomous, cloud, and applications technologies". I assume you think developers are going to suddenly abandon AWS, Python etc and move entirely to a…

at large firms the clueless technology managment often buy based on the marketing crap, then force it down the throats of the engineers

at my firm we're being all but forced to use Azure even though it costs more and makes absolutely no sense whatsoever for the domain, but since it's the "technology strategy" fighting it becomes exceptionally difficult

Re: MongoDB History

#46

Post by manigandham »

threeseed wrote: post #25
manigandham wrote: post #16

Earlier quoted context omitted.

Sounds like a bad architect or someone who only knows surface features and doesn't have experience with the actual databases. Adding a column is not hard in any relational database, and pretty much all modern ones support no-downtime transactional schema updates with backfills, concurrent index builds, etc. Also the schema always exists somewhere, and it's usually to put it in the database so it's next to (and valida…

Database schemas only validate the data type and whether it's null or not. It's next to useless for ensuring data integrity and why every app you see will have data validation inside the code itself. Whether it's checking that an email has a valid structure or that a payment is not negative. Majority of the logic will be the code so it makes no sense to me other than if you have multiple clients accessing that databa…

The shape of a record, property types, foreign keys and more are all critical part of a schema.

Business logic validation is a separate layer but still requires proper types and data integrity underneath, and that's where strong schemas in the database help. More so when you have multiple apps interacting with the same database.

Re: MongoDB History

#47

Post by ralph84 »

threeseed wrote: post #17
slyall wrote: post #8

The "Mongo DB is Web Scale" video just turned 10 years old. I'm pretty sure that was a big factor in MongoDB not being taken seriously by many people. https://www.youtube.com/watch?v=b2F-DItXtZs

Anybody who makes complex technology decisions based on marketing copy doesn't deserve to be taken seriously either. Not that I think these people actually exist other than in the minds of many HN commenters. Oracle on their website right now says "we lead the market in autonomous, cloud, and applications technologies". I assume you think developers are going to suddenly abandon AWS, Python etc and move entirely to a…

Oracle's marketing is more to preserve their existing install base than acquire new customers.

Re: MongoDB History

#48

Post by hodgesrm »

manigandham wrote: post #16
conradfr wrote: post #13

Earlier quoted context omitted.

I interviewed recently at a payment provider that is rewriting its PHP/Mysql monolith in Java & go microservices with MongoDb. The architect would praise static typing but would prefer MongoDb "because it's easier to add a column". It felt weird but I've never used MongoDb so I could not really argue about it.

Sounds like a bad architect or someone who only knows surface features and doesn't have experience with the actual databases. Adding a column is not hard in any relational database, and pretty much all modern ones support no-downtime transactional schema updates with backfills, concurrent index builds, etc. Also the schema always exists somewhere, and it's usually to put it in the database so it's next to (and valida…

Adding columns can be hard at scale. MongoDB allows you to add columns incrementally without stopping the world. You just add the value and it's materialized in the DBMS. The point is you don't have to manually define schema but instead the database works with the structure of the data.

I'm a dyed-in-the-wool RDBMS user but I can see the value of this feature. The trade-off, of course, is that your application has to handle varying schema levels. MongoDB also won't protect you against typos, inconsistent types, and other foolishness. I would not judge people who choose to make this trade--it's a sensible one for many use cases.

Many analytic databases are headed in this direction due to the amount of data that arrives in the form of nested JSON structures. I can't speak for other DBMS types but it's something we're very interested in for ClickHouse.

Re: MongoDB History

#49

Post by jaysonqpt »

chrisfosterelli wrote: post #18

MongoDB still has an awful reputation on Hacker News but I really appreciate the take from "Why RethinkDB Failed" [0]: > People wanted RethinkDB to be fast on workloads they actually tried, rather than “real world” workloads we suggested. For example, they’d write quick scripts to measure how long it takes to insert ten thousand documents without ever reading them back. MongoDB mastered these workloads brilliantly, w…

I think MongoDB 3.6 is when it became a "decent" DB.

Azure CosmosDB provides protocol level for MongoDB 3.6. This offers developers a neat way of using the power of distributed CosmosDB without sacrificing cloud portability.

Re: MongoDB History

#50

Post by jaysonqpt »

numlock86 wrote: post #10
tobyhede wrote: post #4

A complete history with all the data ... unlike MongoDB. Boom tish etc.

I never got a definite answer: What problem does MongoDB even try to solve?

It is a free and open source NoSQL database that can horizontally scale if needed without any additional plumbing. A lot of projects use it due to its simplicity in developer workflow.
Post reply on HN