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

231–240 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#231

Post by ricklepick »

hartator wrote: post #71

Not sure I understand the MongoDB hate here. Migrations and denomalization is not somthing you have to deal with in MongoDB.

This is not totally accruate.

Yes, you still have to deal with migrations. When you change the data model, you have to compensate, either with modifying the underlying data or by compensating for it in code.

"denormalization" is really just structuring your data model for best performance for your underlying data store and code algorithms. And you most certainly have to do this in mongodb as well.

The great thing about using migrations is you pay this price once, at upgrade time. Not in yoru code on every query to the data layer.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#232

Post by ricklepick »

peteridah wrote: post #154

I am quite surprised that companies still use Red Hat Satellite Server. In 2010 while I was still at Red Hat, deploying and managing it was the mainstay of the consulting business, and it was based on Oracle RAC. It was to my mind already legacy software at that time.

Satellite of today is not Satellite of 2010 by any stretch.

Satellite 6 is based on foreman + katello + pulp

Re: Red Hat Satellite to standardize on PostgreSQL backend

#233

Post by ricklepick »

purple_ducks wrote: post #189
leetrout wrote: post #53

Earlier quoted context omitted.

In 2019. A LOT of people want MySQL over Postgres because of ignorance about how far Postgres has came and they don't know/care. I try to explain why I like transactional DDL and the guardrails that come with Postgres. With MySQL you end up having to use Percona to get a really robust DB setup with proper tooling that compares to Postgres in my experience. Both, of course, have plenty of known and unknown knobs you c…

> A LOT of people want MySQL over Postgres because of ignorance or you know, for multi master cluster pretty much out of the box. Gallera DB.

It's rarely as nice in reality as it sounds on paper though...

Gallera DB setups aren't easy, and still have complex issues.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#234

Post by linkmotif »

acdha wrote: post #229
linkmotif wrote: post #210

I’ve never enjoyed Mongo for a second, not conceptually, not practically. But I don’t understand the people who act like Postgres is the end of everything. SQL never felt right for me either. It’s a fine language for business analysis, I guess, but is it actually pleasant for development? Do all of you who so enthusiastically post that it should be the first tool you reach for really never experience object-relationa…

Yes: what you’re really doing is documenting your data structures and access patterns, which is way less work to do consciously rather than trying to bolt it on ad hoc. A really big thing is normalization which some people tend to downplay until they’ve had to write code to recurse complex structures enforcing consistency or making global changes. Similarly, atomicity and isolation are really useful characteristics t…

Right, Postgres is better than document stores, but is it actually pleasant to store your data in square tables and then process it to runtime objects from that? Even with battle tested ORMs, it’s never felt right for me.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#235

Post by qbaqbaqba »

duxup wrote: post #69
bane wrote: post #31

Earlier quoted context omitted.

I once worked at a place that, at some point in the past, had developed some kind of semantic graph database that never gained market traction. The author of it had ended up as CTO and kept seeking out uses for his work and ended up finding all kinds of odd places for it to live, including as the auth database in a large scale document analytics system and running part of the payroll. We were constantly running into…

I worked for a company that was old but had a fancy new product. It was just about to be released when.... A competitor bought us for stupid money. They fired most folks (not my small department) had their CTO decide between our fancy new product, and the product he created. There was no question, our product was amazing, his Frankenstein was two pieces of equipment cabled together in three items the footprint ... an…

Happy ending.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#236

Post by dmoreno »

This sentence, when talking about support for old enterprise versions, is a bit suspicious:

> Satellite will not use newer versions of MongoDB that are licensed under SSPL.

So my read is that there is not only an intention of database consolidation, but also a desire of avoiding the SSPL.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#237

Post by chousuke »

linkmotif wrote: post #234
acdha wrote: post #229

Earlier quoted context omitted.

Yes: what you’re really doing is documenting your data structures and access patterns, which is way less work to do consciously rather than trying to bolt it on ad hoc. A really big thing is normalization which some people tend to downplay until they’ve had to write code to recurse complex structures enforcing consistency or making global changes. Similarly, atomicity and isolation are really useful characteristics t…

Right, Postgres is better than document stores, but is it actually pleasant to store your data in square tables and then process it to runtime objects from that? Even with battle tested ORMs, it’s never felt right for me.

I find it very pleasant, but I also tend to avoid ORMs. I can just write SQL queries to get me the data I need in any form I want, and it's not always useful to stuff that into objects when I can just process it as is.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#238

Post by bunderbunder »

bpye wrote: post #61
bunderbunder wrote: post #33

Earlier quoted context omitted.

I've always preferred the terms "schema on write" and "schema on read" to schemaful/schemaless. At some point, you are always going to have to get the data into some sort of consistent model, so that you can operate on it in a predictable and sane way. So there's no question of there being a schema, even if it's only implicit. The question is, do you apply the schema once, when you write to the data store, so that th…

I'm tired and haven't often dealt with database systems. I'm struggling to see significant benefits for schema on read style systems - maybe progressive migration? I'm not convinced...

I can't speak to document stores very well, but one spot where schema-on-read makes sense is in data warehousing type applications. One of the potential troubles with the traditional ETL approach is that transforming the data to fit a fixed schema almost always involves some information loss that might make the data less suitable for answering certain questions.

That's fine if you can predict what questions your business intelligence or data science team will be asked ahead of time, but, realistically, you can't actually do that. Using a schema-on-read data warehouse instead is a more costly option, but also leaves you more able to respond to changing business demands.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#239

Post by ixtli »

twic wrote: post #215
toomuchtodo wrote: post #5

Earlier quoted context omitted.

I’ll allow it. Years later, I’m still miffed at Graylog (centralized logging engine) for having required MongoDB for a small bit of auth and meta storage that could’ve easily been done in MySQL or PostgreSQL (RDS even), forcing the need for that much more ops work for a small Mongo cluster for HA. Everyone deprecating the use of Mongo is a welcoming turn of events. I shall recall these dark days to the next generatio…

Well, happily, those days are gone for good. Who needs NoSQL when you have the blockchain!

Glorious, cursed comment.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#240

Post by mlevental »

atombender wrote: post #126
mlevental wrote: post #28

Earlier quoted context omitted.

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.

Look at GraphQL. It lets you enforce a single schema from the front end down to the data layer. In my company's product, we specify the data models as JSON Schema, and then generate the necessary language code -- we generate the GraphQL schema from it as well as Go data types, with some database glue. Our front end code is currently JavaScript, but we hope to migrate to TypeScript, which will make everything statical…

https://github.com/grpc/grpc-web
Post reply on HN