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

81–90 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#81

Post by empthought »

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…

     CREATE TABLE pure_document_store(document jsonb NOT NULL);

Re: Red Hat Satellite to standardize on PostgreSQL backend

#82

Post by ams6110 »

d4l3k wrote: post #64
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.

Pretty much all of the things you'd want in a relational database are now present in Mongodb too. The real benefit of MongoDB at this point is the ability to easily scale beyond a single machine with shards and high availability using replica sets. Postgres will get you pretty far, but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. At that point al…

Most databases will never need this kind of scaling.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#83

Post by int_19h »

kjeetgill wrote: post #51
int_19h wrote: post #36

Earlier quoted context omitted.

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

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.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#84

Post by stickfigure »

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

I do a lot of work with both traditional RDBMSes and NoSQL databases.

The main question I would ask is: Is your data schemaless? Often it is - especially when storing what we'd normally call a "document". Heavily polymorphic data is often better stored schemaless. And sometimes you don't necessarily have the schema in advance (common when storing "other people's JSON").

You can store schemaless data in Postgres via the JSONB type, so this isn't necessarily a "Mongo vs Postgres" issue, but more of a general data modeling issue.

As a point of reference, the folks that struggle with schemaless tend to be the ones using Javascript, Ruby, or other type-ambiguous languages. Schemaless is less of a problem in Java and other languages where class structures enforce your schema.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#85

Post by ousta »

seanwilson wrote: post #78
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…

> Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). Do you have any examples of this? It's rare I see suggestions like this. I've done this for HTML mobile apps a few times before where the entire app (fairly simple) state is saved and loaded as JSON when you make any changes. It's super simple and very little can go wrong. This…

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?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#86

Post by atm0sphere »

baroffoos wrote: post #54
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…

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.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#87

Post by atm0sphere »

ams6110 wrote: post #82
d4l3k wrote: post #64

Earlier quoted context omitted.

Pretty much all of the things you'd want in a relational database are now present in Mongodb too. The real benefit of MongoDB at this point is the ability to easily scale beyond a single machine with shards and high availability using replica sets. Postgres will get you pretty far, but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution. At that point al…

Most databases will never need this kind of scaling.

https://m.youtube.com/watch?v=b2F-DItXtZs

Re: Red Hat Satellite to standardize on PostgreSQL backend

#88

Post by int_19h »

seanwilson wrote: post #78
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…

> Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). Do you have any examples of this? It's rare I see suggestions like this. I've done this for HTML mobile apps a few times before where the entire app (fairly simple) state is saved and loaded as JSON when you make any changes. It's super simple and very little can go wrong. This…

I mean, most apps that have configs treat them in this manner. It's just that people assume that configs and other metadata are "small enough", and the actual data they process is not. But when you look at what "small enough" really means on modern hardware - heck, even on 10 year old hardware! - that divide doesn't really follow.

The same thing goes for queries, by the way. When it's in-memory, you often don't even need indices, because linear scans will be "fast enough" on many datasets. And with list comprehensions etc, this can be written just as declaratively as SQL (for an extreme example, see LINQ, which even has outer joins).

And yeah, the "very little can go wrong" part is exactly what's so great about this. It's KISS at work. If you don't really need complexity, why pay the tax?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#89

Post by chrisseaton »

ousta wrote: post #85
seanwilson wrote: post #78

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). Do you have any examples of this? It's rare I see suggestions like this. I've done this for HTML mobile apps a few times before where the entire app (fairly simple) state is saved and loaded as JSON when you make any changes. It's super simple and very little can go wrong. This…

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?

> i struggle to see why in-memory data structure is the way to start can you please explain.

It’s much simpler. The idea is to start simple and avoid complexity. Do you need the extra complexity of a PostgreSQL instance or can you get away with doing it in-memory? If so you can save yourself a lot of complexity.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#90

Post by krferriter »

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.

Schema management and automated migration generation frameworks alleviate a lot of that headache. As long as the schema definitions are well structured and can be easily analyzed against a live db to find diffs and generate migration scripts. Django does this very well. You don't even need to use Django for the application, you can use it purely to define schemas and perform migrations on the DB. I'm sure there are alternatives for other languages.

People who got tired of dealing with schemas are now realizing that having zero schema is way more of a headache and way more work than the up front work of creating the schema.

Post reply on HN