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

191–200 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#191

Post by ilovetux »

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...

One pretty cool use of schema on read is Splunk. It wants to take in all the data and let you search, transform and visualize it in a variety of ways some of which you may not know until you start exploring what data you have.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#192

Post by imtringued »

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.

A lot of useful features don't end up being implemented in Java and even if they do, libraries and frameworks have to update to take advantage of them. With a new language libraries are built from the ground up based on the new features.

For example adding async to the language isn't necessarily going to change your programs to be async because every widely used library has already adopted threads and doesn't support async yet and often never will.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#193

Post by manigandham »

general8bitso wrote: post #190
manigandham wrote: post #162

Earlier quoted context omitted.

Runtimes are different from languages. The C# language has never been rebooted and is fully backwards compatible, and there's no better example of long-term support than Microsoft. You can still run apps from the MSDOS era, and even upgrade MSDOS through to Windows 10 if you have all the CDs today.

So, like DOS 3.3 to 5 to 6.2, and Windows 3 to 3.1, to 95 to 98 to 98SE, to ME, to XP, to 7, to 8 to 8.1, to 10? I think I was using floppies until Win 98?

Here's a 10 hour video from DOS to Win10: https://www.youtube.com/watch?v=l60HHWWo9z4

Re: Red Hat Satellite to standardize on PostgreSQL backend

#194

Post by pwm »

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 agree with the general sentiment just wanted to point out that "my schema is my app layer" has some valid use-cases. At my current job we deal with highly complex schemas (modelling insurance contracts). Correctness is paramount but at the same time you need flexibility in terms of change over time. Defining these schemas at the DB level would be painful, a bit like writing web apps in assembly. Languages like Haskell (which we use) help here with their rich and expressive typing capabilities, so we can model these complex domains expressively and use the DB only for persistence. Admittedly it does have downsides, like having to write your own migration layer, but for this use-case the benefits outweigh the pains.

PS.: We do use Postgres though ;) as it has 1st class json support and at the same time we have the luxury of using its relational capabilities where needed (think of a hybrid model).

Re: Red Hat Satellite to standardize on PostgreSQL backend

#195

Post by zepolen »

nodesocket wrote: post #15
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?

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…

> what is the best pure document store database then?

That is like asking what's the best horse species to use for transporting goods.

Doesn't matter.

You want a diesel truck.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#196

Post by zaphirplane »

jayd16 wrote: post #76
Thaxll wrote: post #45

Earlier quoted context omitted.

Your comment makes no sense since RH is moving for reasons different that "MongoDB is bad".

Not being worth the effort isn't much better.

You are assuming it’s the technology I’m assuming it’s the licensing change.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#197

Post by zaphirplane »

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?)

The licensing change surely has to have played a factor

Re: Red Hat Satellite to standardize on PostgreSQL backend

#198

Post by zaphirplane »

geggam wrote: post #66
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…

why would you require the latest version of a database to not have corrupt data ? I can install 10 yr old database postgres / mysql software and not get corrupt data

No data corruption bugs in the last 10 years is a hard to believe. There was a story here a few days ago about incorrect use of fsync

Re: Red Hat Satellite to standardize on PostgreSQL backend

#199

Post by speedplane »

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…

Maybe I’m a rare exception, but I chose NoSQL early on when it was still “hot” and have never looked back. We’ve grown from a couple megabytes of data do several dozen terabytes and have had countless issues, but scaling our database was never one of them.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#200

Post by imtringued »

int_19h wrote: post #93
ousta wrote: post #85

Earlier quoted context omitted.

i struggle to see why in-memory data structure is the way to start can you please explain. do you create json for all your users?

You create a JSON (for example) for all your users when you need to store it. But in memory, it's just a collection of User objects - or whatever is idiomatic for your PL. And you query it with the same tools your language offers - e.g. sequence comprehensions. So there's no impedance mismatch, and no need for the vastly more complicated code that is needed to bridge it. Even if it's not your code - i.e. if you're us…

That sounds extremely complicated because you have to do the vast majority of work yourself.

>So there's no impedance mismatch, and no need for the vastly more complicated code that is needed to bridge it. Serializing arbitrary data structures is far from trivial, especially because JSON doesn't support references natively and therefore things like cycles are impossible without adding IDs yourself which is incompatible across JSON parsers. The naive way to serialize objects to JSON also tends to cause duplicated objects for every reference.

Or you can just use any SQL Database and use an ORM, write your damn Domain Classes [0], call .save() when you want to save and then query the damn thing [1] and if you want eager loading you can configure that too. Honestly it's so frictionless I don't see why I should bother with whatever your preferred workflow is.

[0] http://gorm.grails.org/latest/hibernate/manual/index.html#do... [1] http://gorm.grails.org/latest/hibernate/manual/index.html#cr...

I'm sure most complaints against ORMs happen because newcomers, who don't have sufficient knowledge of relational databases, try to model arbitrarily complex objects that cannot be mapped to a relational database (and not to JSON without extra support by the parser either) or because they think they don't have to write queries at all. In other words: they are fundamentally trying to swim against the stream and then blame the tool. If you know of the limitations of relational databases then ORMs are just a tool that saves you time and lets you avoid boring work.

Post reply on HN