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

211–220 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#211

Post by orzig »

hartator wrote: post #205
world32 wrote: post #187

Earlier quoted context omitted.

The migration comment has already been addressed. "Denormalization is not somthing you have to deal with in MongoDB." What do you mean exactly? If you have a piece of data, lets say an address, that exists in more than one place as is the mongodb way, you will absolutely have to deal with the fact that you need to now update that data multiple times. So denormalization is very mcuh some you have to deal with in Mongo…

Denormilization is not the thing because normalization of data in document db just results in what will heavy denormalized SQL. Like the address fields will be document inside the document. Instead of user_address_1_zipcode, you’ll get user: addresses: [ { zipcode: ... } ] }. It seems more elegant to me. But, yes you do have to update everywhere manually.

As with so many things, the right answer depends on the expected ratio and complexity of of writes, queries and updates.

Something that I've come to believe is that developers don't spend nearly enough time gathering process data that would let them make explicit forecasts (even order of magnitude). Once your team has aligned on those forecasts, a bunch of design debates just fall away.

If you really want to have fun, start a prediction market - though that might end up creating its own set of debates :)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#212

Post by blattimwind »

krferriter wrote: post #90
djrobstep wrote: post #41

Earlier quoted context omitted.

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

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

In my experience Alembic works more better.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#213

Post by patwolf »

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…

You could do it in a JSON field, and I've personally done that but mostly out of laziness. I think in the end it's better to actually come up with a normalized schema.

I typically reserve JSON fields for storing data whose schema I don't control. For example, when Stripe gives back a giant chunk of JSON after a transaction, I use a JSON field.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#215

Post by twic »

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…

Well, happily, those days are gone for good. Who needs NoSQL when you have the blockchain!

Re: Red Hat Satellite to standardize on PostgreSQL backend

#216

Post by matwood »

sonnyblarney wrote: post #57
int_19h wrote: post #37

Earlier quoted context omitted.

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.

First, most 'noSQL' DB's (including Mongo) have data validations anyhow, rendering the discussion almost moot. " RDBMS provides far more opportunity for validation" This can't be true. The application layer, which ultimately contains all 'knowledge' of all aspects of the business, including data from all other resources, can obviously 'provide more opportunity' for validation than any DB possibly can. Moreover, 'vali…

> The application layer, which ultimately contains all 'knowledge' of all aspects of the business,

Data always outlives the application. You could argue that some app + data lives on together, but then you have just poorly reimplemented what an RDBMS does for you up front.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#217

Post by y4mi »

int_19h wrote: post #156
y4mi wrote: post #153

Earlier quoted context omitted.

I'm pretty sure he's taking about web application... Sqlite is only really viable if you don't have an undefined amount of nodes pushing commits into the DB That's a challenge desktop applications don't have

For many web apps it's true simply because of the expected usage, or sometimes because of access patterns (e.g. when most clients are read-only, or when most users don't author anything). From https://www.sqlite.org/whentouse.html : "The SQLite website ( https://www.sqlite.org/ ) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are…

Thats a website, not a webapp... Its literally the first sentence.

you need interactivity with writes for an actual webapp. sure, you could keep the writes in the browser cache, but then it wouldn't really be a webapp either, more like an app that opens in the browser.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#218

Post by twic »

paxys wrote: post #102
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…

In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. Using Postgres or MySQL is barely more complex than SQLite, and it makes more sense to start with one of them than move everything over once you realize you aren't going to be running on your dev machine forever.

I have numerous real-world use cases in production and making money that use in-memory and local disk databases. In fact, it's mostly hashmaps and JSON files.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#219

Post by twic »

anarazel wrote: post #202
raphaelj wrote: post #201

Earlier quoted context omitted.

IIRC, Postgres use a key-value store internally, so it does not really matters if you store records (i.e. tables) or objects (i.e. JSON documents). There was an article on HN a couple of months ago that was comparing Mongo and PgSQL performance, and PgSQL ended up being as fast if not faster for most use cases.

I don't see how you'd describe postgres validly as a key-value store at the storage level / internally. It's a pretty traditional row-store (without support for index oriented tables), i.e. all columns of a table are stored together. At the storage level there's no designation of what the key of a row is. Of course you can have primary keys, but that's a higher layer concern.

Aren't tables a bit like key-value stores where the key is an object ID and the value is the column values? My understanding is very vague, but i think that came out of PostgreSQL's heritage as an "object-relational" database, even if it's vestigial today.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#220

Post by matwood »

chasd00 wrote: post #105
djrobstep wrote: post #41

Earlier quoted context omitted.

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.

also, DBAs hate developers. Developers want to make changes to the database to support their classes such as "i need to add a column" and the DBA response is "no." or, even worse, "fill out this ticket and it will get prioritized in the next scrum" meanwhile the developer is at a standstill. I interviewed at southwest airlines years ago and i don't remember how it came up but we were talking about bottlenecks or some…

I think you need to also look at it from the DBAs stand point. If they did whatever the developers want and the system goes down or more likely other parts become slow, it is the DBA who gets the call.

In a large company like SW, the developer requesting some change for their app may have no idea how else the db is being used. What if their requested changes took down the db and prevented reservations from working?

My examples are extreme, but I have seen similar things in my years as both a developer and a DBA at times.

Post reply on HN