Live data from Hacker News

Red Hat Satellite to standardize on PostgreSQL backend

redhat.com

51–60 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#51
post #36

Earlier quoted context omitted.

This is the same thing that happened in Java. Other languages started prototyping features... that eventually just end up being implemented in Java.

Java did it way too slow, and that is a significant contributor to it being relegated to "legacy" in many areas. If it waited for the other languages to prototype stuff, it might have not been the case. The problem is that it waited for them to prototype it, refine it, release it, popularize it, and for their community to adopt it, before even starting to work on it in Java - which means that by the time they had it,…

Huh. I didn't know they worked any differently in C#. In what ways are they less powerful in Java?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#52

Earlier quoted context omitted.

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?

I was going to respond with “well, any database that can’t guarantee that kind of backwards compatibility shouldn’t be taken seriously,” but then I realized we are talking about MongoDB and I found myself giggling.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#53
post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

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 can turn to your liking and can make either database appear to be better by any number of metrics for your use case.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#54
post #4

Earlier quoted context omitted.

Smug self-righteousness

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…

Setting up graylog was one of the worst mistakes I made. It took forever to get all the required software installed and configured and then it was taking up all the ram on the server doing fuck all.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#55

Earlier quoted context omitted.

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.

OT: Ubiquiti seem to be ... not good at software and only relatively good at hardware. I'm not sure why they're as popular as they are and I'm slightly ashamed at being suckered in by Troy Hunt's marketing. Is it just a case of the rest of the home/SOHO WAP/router segment is cataclysmically bad, so they only have to be a little bit better? (The WAP is good, but not as fast as the Turris Omnia it replaced).

> I'm not sure why they're as popular as they are

For me it's always been price.

Back when we adopted them Ubiquiti UAPs were pretty much the only thing close to enterprise access points (centralized management, radius support and all that jazz) but at 1/10th of the price of Cisco/Ruckus/Aruba.

I agree that they're a bit overhyped: we have 200+ deployed and they are not exactly the most reliable, some devices just disappear from the controller forever, some early generation ones would just overheat and die, CLI management is non-existent. But hey for $70 a pop you can just buy a truckload of them and replace them as needed.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#56
post #31

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…

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…

This is the definition of software engineering hubris distilled into a few paragraphs

Re: Red Hat Satellite to standardize on PostgreSQL backend

#57
post #37

Earlier quoted context omitted.

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

On the contrary, RDBMS provides far more opportunity for validation, because it has all the data at its disposal, which can be queried as needed without the expense of crossing the boundary.

First, most 'noSQL' DB's (including Mongo) have data validations anyhow, rendering the discussion almost moot.

" RDBMS provides far more opportunity for validation"

This can't be true. The application layer, which ultimately contains all 'knowledge' of all aspects of the business, including data from all other resources, can obviously 'provide more opportunity' for validation than any DB possibly can.

Moreover, 'validation' generally implies aspects which are inherently application specific ergo, doing this purely in the data layer almost implies an intersection of concerns.

Validation in almost every case must be done on the app layer, so anything we get from the DB is an added benefit.

Also, data generally has to be validated when it enters into the business logic, long before it gets into the DB, moreover, there are usually data elements that are not persisted, and must be validated anyhow, again illustrating the requirement for validation above the DB.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#58
post #12

Does someone have the time explain what NoSQL Mongo didn’t do that PostgreSQL does? I guess I don’t really understand the structured SQL vs NoSQL when you aren’t accessing directly but via a program. I also don’t understand why they would have supported a NoSQL and object-relational at the same time at any point.

From reading the post it sounds like they want transactions for some of the functionality they’re trying to build. I guess Mongo still doesn’t have those.

They recently added multi document transactions though.

https://docs.mongodb.com/manual/core/transactions/

Re: Red Hat Satellite to standardize on PostgreSQL backend

#59
post #37

Earlier quoted context omitted.

On the contrary, RDBMS provides far more opportunity for validation, because it has all the data at its disposal, which can be queried as needed without the expense of crossing the boundary.

What is the purpose of validation would you say with modern computers? At one time, specifying the exact number of chars was good for squeezing out as much storage as possible, but less so today.

Validation is almost always a function of business logic, not 'storage compression'.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#60
post #36

Earlier quoted context omitted.

This is the same thing that happened in Java. Other languages started prototyping features... that eventually just end up being implemented in Java.

Java did it way too slow, and that is a significant contributor to it being relegated to "legacy" in many areas. If it waited for the other languages to prototype stuff, it might have not been the case. The problem is that it waited for them to prototype it, refine it, release it, popularize it, and for their community to adopt it, before even starting to work on it in Java - which means that by the time they had it,…

Yeah, or value types. Still waiting on those...
Post reply on HN