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

131–140 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#131

Post by pimeys »

bane wrote: post #31
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…

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 think I know the company. We were almost acquired by them until they hit the rocks and we took a hit. Interesting to hear how that database was a pain to manage.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#132

Post by int_19h »

Scarbutt wrote: post #104
int_19h wrote: post #43

Earlier quoted context omitted.

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 w…

Regarding your first point, even simpler could be to store the json as string in sqlite as to avoid all the file handling stuff, but I would say that sqlite is already a popular solid application format ;)

But the only file handling stuff you need to load JSON from a file is to open the file. And if it's in SQLite, then you'll need to open the database and query - more complicated, no?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#133

Post by int_19h »

thomaslangston wrote: post #100
int_19h wrote: post #77

Earlier quoted context omitted.

First of all, we were talking about validation of data in the database, specifically. > 'validation' generally implies aspects which are inherently application specific Not at all. Taking this at face value implies that some app can write data to the database that is valid according to that app, and then another app can read data that is invalid from its perspective, and have to deal with it. That doesn't make sense…

The general idea I've seen (for both SQL and NoSQL databases) is two apps never should write to the same database to ensure separation of concerns. Some API layer instead handles all write operations. Disclaimer: MongoDB employee. All opinions are my own.

It doesn't matter in this case - all that matters is that they share the same data store, regardless of how concurrent access to it is organized. The problem here isn't concurrency, but the semantics of data stored - if one app can change it such that the other app can later retrieve data that it considers invalid according to its business constraints, what is the other app supposed to do?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#134

Post by chousuke »

thomaslangston wrote: post #100
int_19h wrote: post #77

Earlier quoted context omitted.

First of all, we were talking about validation of data in the database, specifically. > 'validation' generally implies aspects which are inherently application specific Not at all. Taking this at face value implies that some app can write data to the database that is valid according to that app, and then another app can read data that is invalid from its perspective, and have to deal with it. That doesn't make sense…

The general idea I've seen (for both SQL and NoSQL databases) is two apps never should write to the same database to ensure separation of concerns. Some API layer instead handles all write operations. Disclaimer: MongoDB employee. All opinions are my own.

You only need a separate API layer if the database can't enforce constraints properly.

The database schema (along with stored procedures, views etc.) is an API and database engines are designed to have multiple concurrent writers. Multiple applications and users needing access to the same data is largely why databases exist in the first place.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#135

Post by int_19h »

sonnyblarney wrote: post #101
int_19h wrote: post #77

Earlier quoted context omitted.

First of all, we were talking about validation of data in the database, specifically. > 'validation' generally implies aspects which are inherently application specific Not at all. Taking this at face value implies that some app can write data to the database that is valid according to that app, and then another app can read data that is invalid from its perspective, and have to deal with it. That doesn't make sense…

"data is data, it's either valid, or it's not. That's why the schema is about the data, not about the app." This is not true. The objective of the overall app/system (i.e. front/back/middle/DB/storage/services etc.) is to carry out some kind of business logic. A DB schema cannot fully validate stored data against the logic. Otherwise we wouldn't write backend code, we'd just write a bunch of schemas and be done with…

> The DB may only care that it's UTF and max 20 chars. But the system requires more validation than that.

Are you familiar with SQL constraints, triggers, user-defined functions, stored procedures?..

Re: Red Hat Satellite to standardize on PostgreSQL backend

#136

Post by Scarbutt »

int_19h wrote: post #132
Scarbutt wrote: post #104

Earlier quoted context omitted.

Regarding your first point, even simpler could be to store the json as string in sqlite as to avoid all the file handling stuff, but I would say that sqlite is already a popular solid application format ;)

But the only file handling stuff you need to load JSON from a file is to open the file. And if it's in SQLite, then you'll need to open the database and query - more complicated, no?

I think is more complex than that, when you modify some data structure in memory you also want write to disk immediately as to not lose any data in case of a crash, so this means to write the new file under a separate name and then renaming the new file to replace the old file only after it has been successfully written as to provide safety against storage corruption.

I wouldn't recommend this to a beginner, the sqlite driver(of your language) would handle all this for you in a safe way.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#137

Post by int_19h »

eropple wrote: post #96
int_19h wrote: post #83

Earlier quoted context omitted.

For example, in Java, lambdas cannot capture mutable variables from the outer scope - it must be final, or effectively final. C# always let you do that, from the very first implementation of lambdas.

C# lets you do that because C# doesn't have a way to declare a local readonly/final variable at all . I significantly prefer features that encourage the use of `final` variables everywhere that it is possible in Java. I write C#, Java, and Kotlin in roughly equal measure. Each has its pluses. But the claim that Java's lambdas are worse because it doesn't let you--and this was a conscious design choice!--do something…

C# could do the "effective final" rule, same as Java did - don't allow a variable to be closed over if it's mutated anywhere.

And yet it didn't - which made implementation that much more complex, since capturing mutable locals requires lifting them to extend lifetime.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#138

Post by ako »

mikekchar wrote: post #74
bpye wrote: post #61

Earlier quoted context omitted.

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

When you want to do validation depends on when you can do something about it. I work with a NO-SQL DB at work and while it wouldn't be my choice for most things I would use a DB for, the lack of validation has some benefits. A good example is where you have no ability to validate input from a user, but where you need to store the data anyway. The last thing you want is your noisy data being kicked out by the DB becau…

The default design pattern for storing potentially invalid data with RDBMS is to (usually bulk) load the data in tables without constraints (loading tables), then do the validation in the database, and move valid records to their final tables.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#139

Post by adw »

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…

The best document store is probably either a filesystem or S3.

Use a relational database. Postgres or MySQL. MySQL used to be heinous 20 years ago, but it's alright now. That's about how long these things take.

The primary thing you want from your data storage layer is you want it to be boring. You want all of the foot-shooting to have happened to other people and to be painstakingly documented. This is what relational databases give you. Are they the most ideal thing in the world always? Heck no. Are they extremely well-understood, operationally and in terms of the performance envelope? Compared to everything else, yes.

When in doubt, do the boring thing.

If your data storage layer is interesting, you're a database company and you know to ignore me. Otherwise why are you spending complexity budget on something which isn't the problem you're actually trying to solve?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#140

Post by [deleted] »

bubaflub wrote: post #4
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?

Smug self-righteousness

[deleted]
Post reply on HN