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

Red Hat Satellite to standardize on PostgreSQL backend

redhat.com

Post reply on HN
Print view View original

21–30 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#21

Post by sonnyblarney »

toomuchtodo wrote: post #8
Bucephalus355 wrote: post #7

Earlier quoted context omitted.

Can you explain in more detail about “my schema is my app layer”? EDIT: fixing autocorrect

MongoDB by default is (was? It’s been a while since I’ve used it) schemaless, which means all of your data validation must take place in your app instead of the database. Your data integrity is then only as good as your weakest validation. Edit: scheme/schema autocorrect typos corrected. Thanks!

RDBMS only provides a limited degree of 'validation'. It still must exist fairly comprehensively in the app.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#22

Post by nodesocket »

AznHisoka wrote: post #16
nodesocket wrote: post #15

Earlier quoted context omitted.

This is a dead horse that's been beaten to death over and over again here on HN. MongoDB is garbage. MongoDB doesn't scale. MongoDB is $h!t says HN users. It just feels like an echo chamber. Are you running the latest version of MongoDB in a replica set with journaling enabled and write concern set to one? MongoDB has worked great for my uses, up to moderate write/read scale. Sure, if you are running "big data" or en…

"Are you running the latest version of MongoDB?" I don't use MongoDB, but I imagine the answer to that question for most people is: No, because I already have an existing product in production with actual customers, and I can't afford to upgrade to the latest version.

With a replica set you should be able to do the update with zero or little downtime with some planning. Of course you'll have to look and watch for breaking changes if you running a really old version.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#23

Post by nodesocket »

metildaa wrote: post #19
nodesocket wrote: post #15

Earlier quoted context omitted.

This is a dead horse that's been beaten to death over and over again here on HN. MongoDB is garbage. MongoDB doesn't scale. MongoDB is $h!t says HN users. It just feels like an echo chamber. Are you running the latest version of MongoDB in a replica set with journaling enabled and write concern set to one? MongoDB has worked great for my uses, up to moderate write/read scale. Sure, if you are running "big data" or en…

Modern Mongo still seems to corrupt itself on the Unifi Cloud Controller I have to deal with if there is no disk space left or hard power off. Postgres will be usable after disk space is freed, or when booted back up. This is a really basic reliability issue.

I'm going to go out on a limb and say Unifi Cloud Controller is not running the latest version and does not have journaling enabled.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#24

Post by WrtCdEvrydy »

toomuchtodo wrote: post #18
chisleu wrote: post #17

Earlier quoted context omitted.

Right, but most people using it use model or data repository patterns to ensure correctness. It does offer nearly infinite flexibility provided you use it correctly. You can add fields without any sort of DB work, you just start adding fields to rows as needed and let it catch up organically. There are use cases where mongo makes a lot of sense. It's very popular in the node.js / RAD world for sure. I certainly have…

Unfortunately, I’d argue PostgreSQL gets you all the same benefits with JSON storage (fairly equivalent to Mongo docs), while also giving you all the goodness of a relational, transactional, schema enforcing RDBMS. PGSQL became Mongo faster than Mongo could become PGSQL.

This is the same thing that happened in Java.

Other languages started prototyping features... that eventually just end up being implemented in Java.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#25

Post by AznHisoka »

nodesocket wrote: post #22
AznHisoka wrote: post #16

Earlier quoted context omitted.

"Are you running the latest version of MongoDB?" I don't use MongoDB, but I imagine the answer to that question for most people is: No, because I already have an existing product in production with actual customers, and I can't afford to upgrade to the latest version.

With a replica set you should be able to do the update with zero or little downtime with some planning. Of course you'll have to look and watch for breaking changes if you running a really old version.

It's not just the downtime. It's the actual work involved in running all your regressions to ensure backward compatability. ie. do all your existing queries still work? do all your current backup processes still work? did that arcane config variable you rely on change its stinking name?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#26

Post by dralley »

emmanueloga_ wrote: post #10
Bucephalus355 wrote: post #6

Earlier quoted context omitted.

Wow was MongoDB really that bad?

Possible alternative headline: "Company weights in trade-offs of having two different database systems, decide to consolidate into a single one." :-) They don't give too many reasons, but say that operationally it is gonna be easier for them to work with a single database than with two (no-brainer?)

As someone on the team, that didn't factor into the decision too much, although it's definitely a nice perk.

Switching to Postgres made a lot of sense even when looking at Pulp as a standalone project rather than as a part of Satellite.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#27

Post by taude »

emmanueloga_ wrote: post #10
Bucephalus355 wrote: post #6

Earlier quoted context omitted.

Wow was MongoDB really that bad?

Possible alternative headline: "Company weights in trade-offs of having two different database systems, decide to consolidate into a single one." :-) They don't give too many reasons, but say that operationally it is gonna be easier for them to work with a single database than with two (no-brainer?)

Except, I'd argue that most large distributed systems these days are using much more than two types of data stores, especially when you start including name/value keystores (and in memory caching variants), big data pipelines, transactional data, "unstructured" data storage (like Mongo), time series, etc.

I work in FinTech and you'll see several backing our apps, and this isn't uncommon.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#28

Post by mlevental »

foobiekr wrote: post #14
Bucephalus355 wrote: post #6

Earlier quoted context omitted.

Wow was MongoDB really that bad?

A way to think about that question is to ask whether typelessness in general is bad because a lot of the schemaless databases come from that side of the divide. I’d personally answer yes, but that’s because I believe that typed, schema-generates structures should be pushed all the way from the database to the typescript code on the front end. Changes become something you can deal with with high confidence and things…

how do you do this? tie it all the way from the DB to the client?

incidentally I believe this is the difference between being an engineer and being a product person. I straddle the line. in theory I want a strong type system so I can be confident about the future. in practice I don't want to pay the upfront cost and I'm more interested in shipping now and taking on debt.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#30

Post by jacques_chester »

mlevental wrote: post #28
foobiekr wrote: post #14

Earlier quoted context omitted.

A way to think about that question is to ask whether typelessness in general is bad because a lot of the schemaless databases come from that side of the divide. I’d personally answer yes, but that’s because I believe that typed, schema-generates structures should be pushed all the way from the database to the typescript code on the front end. Changes become something you can deal with with high confidence and things…

how do you do this? tie it all the way from the DB to the client? incidentally I believe this is the difference between being an engineer and being a product person. I straddle the line. in theory I want a strong type system so I can be confident about the future. in practice I don't want to pay the upfront cost and I'm more interested in shipping now and taking on debt.

What upfront cost?
Post reply on HN