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

171–180 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#171

Post by oblio »

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 whole point of NoSQL was scaling to tons of writes. If you don't have "big data" or it can't handle it, then what's the whole real reason of existence for these things?!? :)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#172

Post by chrisseaton »

int_19h wrote: post #83
kjeetgill wrote: post #51

Earlier quoted context omitted.

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

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.

What’s the memory model for captured variables being mutated by multiple threads?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#173

Post by ATsch »

atm0sphere wrote: post #86
baroffoos wrote: post #54

Earlier quoted context omitted.

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.

There were single script 1-click installs for it in bash all over for me..but yeah jvm is a hog.

I think "jvm is a hog" misattribution is actually part of the cause of "jvm being a hog". It implies that you don't need to worry about your memory management and efficiency in Java, because any hoggyness is the jvm's fault. With GC, you can just get away with having memory leaks everywhere and allocate millions of objects per second without any catastropic consequences. JVM software written with knowledge of memory management and that allocation isn't free can perform just as well as any other platform. As Bryan Cantrill loves to say in ever single talk: "gc is not your problem, allocation is your problem, GC just defers the cost".

Re: Red Hat Satellite to standardize on PostgreSQL backend

#175

Post by willvarfar »

sandGorgon wrote: post #164
willvarfar wrote: post #159

Earlier quoted context omitted.

And other regular RDBMS like MariaDB and MySQL have much the same functionality. I store JSON in RDBMS all the time.

interesting - i never knew that. I use postgresql, so dont have first hand knowledge, but i saw this https://tableplus.io/blog/2018/09/mariadb-vs-postgresql-a-qu... > JSON support: PostgreSQL supports JSON and JSONB while MariaDB doesn’t. It supports an alias for JSON instead, which is a LONGTEXT column. Even the proposed json column, is not indexed - postgresql jsonb is indexed and queries fast.

Yeah MariaDB got 'dynamic columns' first, which iirc supported key values but not arrays, and then MySQL added a more complete 'json' data type, so the exact functionality differs by flavour and version.

The postgres support is simply nicer to use and more powerful, e.g. the indexing.

But if your RDBMS is any fairly-recent version of MariaDB or MySQL, you can use JSON too.

Of the top of my head, the thing I find most griping about the MySQL syntax is you have to do

    thing->>"$.key"
instead of postgres-style

    thing->>'key'
Whereas what I really want to be able to do is

    thing.key
But most of the consumers of these modern 'dynamic columns' are apps and then it all really matters less if you don't spend all your days at the sql prompt writing stuff by hand.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#176

Post by dominotw »

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…

It was just a discovery phase.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#177

Post by zaarn »

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…

>A DB schema cannot fully validate stored data against the logic.

Postgres actually lets you run triggers and similar that can validate data arbitrarily. You can even do web requests with the right extension.

If that is not enough, you can run Python code in your database instead and do the same thing with a slightly more powerful language for general purpose computation.

You could write the entire logic of any business app in a PG database and only use the app as a shiny view layer.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#178

Post by pilif »

BossingAround wrote: post #157

A silly, genuine question: when I'm writing a NodeJS app, and I need to store a JSON in a DB that looks like this: { "a" : "b", "c" : { "ca":"cb", "cd":"ce" }, "d": { ... } } How do I store it? To me, NoSQL seemed like the choice in the past. This is not difficult in relational DBs, but it requires rather long SQL commands, and SQL table design. It seems to me that "MongoDB.insert(obj)" seems like the way to go, as i…

> How do I store it? To me, NoSQL seemed like the choice in the past.

If you're using postgres, you could use a column of type jsonb. Postgres comes with many operators and functions (https://www.postgresql.org/docs/11/functions-json.html) to query into jsonb typed columns and many of them even allow index usage for very quick access.

However, the other option would be to use proper SQL tables and normalization to store your data. Then you can query very easily for your data and by making use of a real typed schema, you get free validation of your input and protection against corrupted data later down the line.

And aggregating your information to produce reports over various documents becomes very easy too.

Here's above schema in SQL DDL, Postgres dialect. I'm not sure about nullability and types of your values, but by making use of database types and constraints, you can describe the shape of your data much better which further helps you preventing invalid data from being stored due to bugs

    create table things (
        id bigserial primary key,
        a text not null
    );

    create table c_things (
        thing_id bigint not null 
            primary key 
            references things (id) on delete cascade,
        ca text not null,
        cd text not null
    );

    create table d_things(
        thing_id bigint not null 
            primary key 
            references things (id) on delete cascade
        -- ...
    )

Re: Red Hat Satellite to standardize on PostgreSQL backend

#179

Post by fauigerzigerk »

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…

I don't think the number of records is the right benchmark.

The reason why data is better kept in a database system is because it often has a very different life cycle than applications. It often lives longer and gets used by more than one application. That's why modelling and storing data somewhat separately from applications often makes sense regardless of the amount of data you have.

Also, procedural code is often far more complicated than a SQL query regardless of the number of records being processed. But that obviously depends very much on the specific problem, on the programming language and on the developer's skill set.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#180

Post by amarraja »

PurpleRamen wrote: post #166
sandGorgon wrote: post #158

Earlier quoted context omitted.

postgres has a jsonb datatype that works pretty much like mongodb. https://blog.codeship.com/unleash-the-power-of-storing-json-...

But will it perform as good as a dedicated nosql-db? Will the abilitys match? The querys? There usually is a tradeoff when something is forced into something alien. Is this the case here too?

> There usually is a tradeoff when something is forced into something alien.

Exactly! My thoughts whenever I see people using nosql databases.

Post reply on HN