MongoDB History • Hacker News Board

Re: MongoDB History

#31

Post by trashcan » Sat, Sep 05, 2020, 12:24 AM UTC

manigandham wrote: post #15

numlock86 wrote: post #10

Earlier quoted context omitted.

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

Schemaless data (or at least schema-on-read rather than on-write) is the primary feature. Store JSON documents and index on any field. Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. These days there's not much benefit over a JSON field in…

> Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup.

What applications are much better in your opinion?

Re: MongoDB History

#32

Post by kvn_95 » Sat, Sep 05, 2020, 12:32 AM UTC

threeseed wrote: post #19

numlock86 wrote: post #10

Earlier quoted context omitted.

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

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.

I would also add that the replica set concept that is based on Raft [0] allows for built-in high availability, so the individual servers can be maintained while the whole set is running and servicing clients.

[0] https://en.wikipedia.org/wiki/Raft_(computer_science)

Re: MongoDB History

#33

Post by mattbillenstein » Sat, Sep 05, 2020, 12:37 AM UTC

Mongo is much maligned here and I hesitate to even comment for fear of attack, but in my mind it has some compelling use cases and after Wired Tiger became the default storage engine, that pretty much solved the issues with compaction I had seen in the past while delivering a lot more performance.

I've built systems with it where we didn't own the schema - we were scraping data from other places and schemaless was a feature. And I benchmarked it against Postgres and a couple other things and I just couldn't get the same performance - note our operations were idempotent to the db, so even in a hard crash, we could just re-run the scraping job and we wouldn't really "lose" any data -- or even if the data was stale by a day, not a big deal... That system would do tens of millions of upserts per night on not crazy AWS hardware and it ran for years like this without problems.

Would I use mongo for situations where I needed transactions? Almost never - I actually like Postgres a lot and it's my default for your run of the mill CRUD apps since you can do geo, crypto, search, etc by just installing a few extensions. Do I got on HN on every mongo article and bash them constantly? No, I think they've built a pretty decent thing if you understand the implications of not confirming writes to replicas and whatnot and tune it to your needs.

Re: MongoDB History

#34

Post by RedShift1 » Sat, Sep 05, 2020, 12:37 AM UTC

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 examples you give are perfectly possible in any decent SQL server (mssql, postgres). If anything, database servers are made to ensure data consistency, checks like "payment not negative" are no brainers. If you don't define these constraints at the database level you are leaving its power on the table and are re-inventing the wheel by putting it in your application layer somewhere.

Re: MongoDB History

#35

Post by fiedzia » Sat, Sep 05, 2020, 12:39 AM UTC

threeseed wrote: post #30

fiedzia wrote: post #28

Earlier quoted context omitted.

>There is this myth that schemas must be enforced at the database level. You must have single point to enforce anything. This is very rarely the case with the app, where a) there will be 20 places that access database and b) often some tasks are done by operating on a database directly Some rules cannot be enforced by database, sure, but "a field must exists and be a string" is infinitely better than noting.

You do have a single point to enforce everything: code. In most cases it is only a single web app connecting to a database and in micro-services architectures you can enforce it through a shared database access library. And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent. Quite sure you wouldn't be able to get PCI/HIPAA certified with…

>You do have a single point to enforce everything: code

"code" usually is made of many smaller parts, what will keep those in sync to enforce anything? You are placing a burden on a developer (even more likely - on a group of developers), that just doesn't work in practice.

> And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent

Sure. But without schema at database level, there is no "security layer" to rely on. And you will eventually need to make a change that cannot be done via UI.

Re: MongoDB History

#36

Post by zaphirplane » Sat, Sep 05, 2020, 12:39 AM UTC

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…

The comparison here is DB schema + DB schema migration + shared data access layer vs shared data access layer With that I am not clear on what you think the problem is without domain knowledge.

I can understand broadly that RDBMS is better when you have joins and foreign key constraints and nosql is cheaper “web” scale plus there are ACID considerations yet without domain knowledge it’s plausible nosql is better

Re: MongoDB History

#37

Post by zaphirplane » Sat, Sep 05, 2020, 12:45 AM UTC

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…

In companies with DBAs the constrains are baked into the DB, in places without DBAs (or weak DBAs dev relation) that is absorbed into the code.

To be fair depending on the culture of the company it maybe easier to put in code and update it there than to wait to have it approved, discussed and scheduled by the DBA

Re: MongoDB History

#38

Post by numlock86 » Sat, Sep 05, 2020, 12:45 AM UTC

threeseed wrote: post #19

numlock86 wrote: post #10

Earlier quoted context omitted.

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

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?

Re: MongoDB History

#39

Post by xtracto » Sat, Sep 05, 2020, 12:48 AM UTC

conradfr wrote: post #13

skywhopper wrote: post #5

Lots of interesting info, and I really like working with MongoDB. But I am baffled by the claim that "MongoDB is the king." In all the circles I work in, I only hear Mongo dismissed as a joke. Unfortunately the company's dismissiveness of RDBMSes, their hubris in pushing NoSQL, and their blunders over what are extremely poor default settings all combine to make MongoDB something I don't see anyone taking seriously. I…

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.

Re: MongoDB History

#40

Post by Scarbutt » Sat, Sep 05, 2020, 12:48 AM UTC

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…

RDBMS can enforce data integrity through normalization (avoiding update anomalies), are you familiar with these? https://www.postgresql.org/docs/13/ddl-constraints.html

That doesn't mean that treating your database as a dumb datastore and having the "smarts" in the application layer doesn't work better for some applications. Both ways have trade-offs.