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

31–40 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#31

Post by bane »

toomuchtodo wrote: post #5
bubaflub wrote: 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…

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 all kinds of scalability issues where this 12 year old component was often the source of our pain, but he'd never even entertain a conversation to eliminate it and consolidate or replace it with something better.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#33

Post by bunderbunder »

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!

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 the data at rest is consistently structured? Or do you allow it to be inconsistent in the storage layer, and instead apply the schema and re-validate the data every time you read from it?

There are valid reasons why one might choose either approach.

Which is not to say that valid reasons always play in to the decision to choose one approach or the other.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#35

Post by jacques_chester »

sonnyblarney wrote: post #21
toomuchtodo wrote: post #8

Earlier quoted context omitted.

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.

Databases are, as their name suggests, closest to the data.

Applications generally can't recreate ACID properties and specifically, they shouldn't be trying to.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#36

Post by int_19h »

WrtCdEvrydy wrote: post #24
toomuchtodo wrote: post #18

Earlier quoted context omitted.

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.

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, most people who needed it were already elsewhere (not necessarily off JVM, just another language).

Lambdas were a very good example - if you look at the closest competitor, C#, it got the first take on them back in 2005. Then a major refinement in 2008, adding type inference. By 2010, lambdas were idiomatic in C#. Java, in contrast, released the first version in 2014. And even then, they're still less powerful.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#37

Post by int_19h »

sonnyblarney wrote: post #21
toomuchtodo wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#38

Post by mehrdadn »

Bucephalus355 wrote: post #6
alrs wrote: post #2

Is there a word for a case of "I told you so" that went on for so long that it curdled from frustration, to despair, to cynicism, to a realignment of your understanding of the human project as something barely capable of tying its own shoes and making it out to the mailbox and back?

Wow was MongoDB really that bad?

I'm not sure, but I've seen things like this: https://twitter.com/hackernewsonion/status/38257854706983731...

Re: Red Hat Satellite to standardize on PostgreSQL backend

#39

Post by int_19h »

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…

Strong typing and schemas are a bit different. They're often conflated, but once you start thinking about more complicated examples, this makes sense.

Look at Clojure for a good example - it is strongly (but dynamically) typed, but then it also has schemas with automatic validation on top of it (Spec).

Re: Red Hat Satellite to standardize on PostgreSQL backend

#40

Post by [deleted] »

throwaway5752 wrote: post #20
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…

"my scheme is my app layer" To be fair you can do use schema validators in Mongo. Not sure it's widespread in practice. And there are other distributed databases that aren't document stores that have schemas and various subsets of SQL implemented.

[deleted]
Post reply on HN