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

41–50 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#41

Post by djrobstep »

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…

My pet theory is that NoSQL took off purely because people were sick of having to manage schema changes.

Unfortunately, people reacted to being (justifiably) frustrated with schemas by throwing strict schemas out entirely, instead of making better schema management/migration tools.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#42

Post by liquidise »

bane wrote: post #29

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

"Very compelling reasons" means different things to different people. Which i suppose is a catch 22. The young but introspective dev may make the wrong call on a side project and learn to stick to psql in the future.

The dev who is convinced "web scale" will arrive before their first AWS bill and picks Mongo as their production database will have a worse fate. As will their team and company by proxy.

Rule #1: Always start with PostgreSQL. You don't have a compelling reason not to.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#43

Post by int_19h »

bane wrote: post #29

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

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format).

If you need ACID, then start with SQLite.

If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to.

(But I suspect that most NoSQL apps these days would do just fine with SQLite, perf-wise. As an industry, we don't have a good sense of scale.)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#44

Post by Bucephalus355 »

int_19h wrote: post #37
sonnyblarney wrote: post #21

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.

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.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#45

Post by Thaxll »

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?

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

Re: Red Hat Satellite to standardize on PostgreSQL backend

#46

Post by justinclift »

nodesocket wrote: post #23
metildaa wrote: post #19

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.

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.

> is not running the latest version

MongoDB's not still in early prototype phase or similar is it? Basic reliability shouldn't really need the latest version any more, a few years in. :)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#47

Post by 616c »

bunderbunder wrote: post #33
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!

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…

Excellent perspective. I start using this at work!

Re: Red Hat Satellite to standardize on PostgreSQL backend

#48

Post by voltagex_ »

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.

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

Re: Red Hat Satellite to standardize on PostgreSQL backend

#49

Post by staticassertion »

djrobstep wrote: post #41
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 pet theory is that NoSQL took off purely because people were sick of having to manage schema changes. Unfortunately, people reacted to being (justifiably) frustrated with schemas by throwing strict schemas out entirely, instead of making better schema management/migration tools.

Tell that to AWS. They've banned relational databases for specific workloads because Dynamo (nosql) provides more consistent performance, and is easier to operate.

Tons of conflation of Mongo's problems with those of nosql in this thread.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#50

Post by ajcodez »

djrobstep wrote: post #41
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 pet theory is that NoSQL took off purely because people were sick of having to manage schema changes. Unfortunately, people reacted to being (justifiably) frustrated with schemas by throwing strict schemas out entirely, instead of making better schema management/migration tools.

I think it also has to do with the source of data. If you receive data from a third party it’s easy to insert the whole document and figure out what parts you need later. If your data comes from your own client interface it makes more sense to build up the data model over time.
Post reply on HN