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

251–260 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#251

Post by janee »

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…

I suppose the answer, like all db answers are..it depends :)

My take on it is if the structure of "c" isn't likely to vary wildly over different entries and you have use cases that need queries like:

get rows where c.ca == x and/or c. == x

...and either the frequency or table size makes it unfeasible to scan through all entries, I'd opt for using a relational storage solution and chuck "c" into its own table with a foreign key entry in the original data structure.

Otherwise a non-relational structure could suite it better, in which case you can still use Postgres or SQLServer or any other relational DBMS that supports json. I'd make the deciding factor in that case more about what do I forsee myself using for other use cases, e.g. if I'm already using a RDBMS for other models in the same app then just keep using it, but if not and all my data are arbitrary blobs of JSON then use any ol document store ¯\_(ツ)_/¯¯

Re: Red Hat Satellite to standardize on PostgreSQL backend

#252

Post by dralley »

ricklepick wrote: post #232
peteridah wrote: post #154

I am quite surprised that companies still use Red Hat Satellite Server. In 2010 while I was still at Red Hat, deploying and managing it was the mainstay of the consulting business, and it was based on Oracle RAC. It was to my mind already legacy software at that time.

Satellite of today is not Satellite of 2010 by any stretch. Satellite 6 is based on foreman + katello + pulp

And, for anyone who has experience with Satellite 6.0/6.1... it has gotten much, much, much better since then.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#253

Post by tim333 »

pjc50 wrote: post #245
arendtio wrote: post #227

Earlier quoted context omitted.

The biggest problem with SQLite is that it seems to be easy to use it wrong. If you are using SQLite as it is supposed to be used, it has much better performance than its reputation suggests.

In what way?

Not quite sure but Quora suggests

>[slow]...This is because the entire database was locked every time someone viewed the page because it contained updates/inserts.

So avoid loads of inserts I guess https://stackoverflow.com/questions/54998/how-scalable-is-sq...

Re: Red Hat Satellite to standardize on PostgreSQL backend

#254

Post by bunderbunder »

int_19h wrote: post #43
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 w…

That seems like good advice for smaller-scale web development, and extremely good advice for single-user applications.

If you're working on a larger scale, or expect to be growing into a larger scale, though, then I think it's wise to skip straight to using a full-blown RDBMS. It's not about scalability, per se - very, very few projects need more performance than SQLite can deliver - so much as about manageability. A top-tier RDBMS will have a better story for resiliency and availability, it will have a more robust security model, it will handle concurrency better, it will have a more complete SQL dialect that allows you to handle more complex queries while keeping them more maintainable, etc.

This is one of the few spots where I think YAGNI doesn't apply. In expectation, it's cheaper to start on the RDBMS than it is to start small and grow as needed. The costs of switching databases are so high, the costs of outgrowing your data layer are even higher, and the costs of trying (and, usually, failing) to keep your data layer database-agnostic are still higher yet, and, in that particular problem domain, the likelihood of eventually being able to benefit from an industrial-grade RDBMS is so easy to anticipate.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#255

Post by CydeWeys »

tim333 wrote: post #253
pjc50 wrote: post #245

Earlier quoted context omitted.

In what way?

Not quite sure but Quora suggests >[slow]...This is because the entire database was locked every time someone viewed the page because it contained updates/inserts. So avoid loads of inserts I guess https://stackoverflow.com/questions/54998/how-scalable-is-sq...

There's plenty of use cases where you want to record analytics or metrics for each page load though -- so I guess SQLite simply isn't suitable for that?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#256

Post by trashcan »

pjc50 wrote: post #245
arendtio wrote: post #227

Earlier quoted context omitted.

The biggest problem with SQLite is that it seems to be easy to use it wrong. If you are using SQLite as it is supposed to be used, it has much better performance than its reputation suggests.

In what way?

Writes require an exclusive file handle/lock (only one write can happen at a time), so read heavy uses are usually a better match.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#257

Post by acdha »

linkmotif wrote: post #234
acdha wrote: post #229

Earlier quoted context omitted.

Yes: what you’re really doing is documenting your data structures and access patterns, which is way less work to do consciously rather than trying to bolt it on ad hoc. A really big thing is normalization which some people tend to downplay until they’ve had to write code to recurse complex structures enforcing consistency or making global changes. Similarly, atomicity and isolation are really useful characteristics t…

Right, Postgres is better than document stores, but is it actually pleasant to store your data in square tables and then process it to runtime objects from that? Even with battle tested ORMs, it’s never felt right for me.

ORM design definitely matters — I mostly use the Django ORM which generally feels right and has convenient escape hatches — but I've also seen a fair number of cases where people complaining about the ORM were really reflecting the fact that their project's data model was somewhat off of what it wanted to be and a migration was in order.

The real win for me is once you're doing anything more than just loading an object: once you need to do any sort of reporting, filtering, querying, etc. I appreciate the effort spent on normalization.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#258

Post by kevin_thibedeau »

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?

Open the file, parse its content, deal with any errors. SQLite is simpler.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#259

Post by jeffdavis »

int_19h wrote: post #119
jeffdavis wrote: post #107

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)." That sounds like a bad idea in many cases. Prone to many kinds of problems, like accidentally corrupting the stored state beyond recognition from a tiny application bug.

How exactly would you corrupt it? For all the stuff that's in-memory, it's as safe as your language is. If you're writing it to disk all at once, it's easy to implement this atomically with rename - this guarantees that you have either the old file or the new file, but not some weird in-between state. And if you mean corrupting by the app going amok and asking to corrupt data because of logic errors in the app itself…

Create some ID that's supposed to be unique, and due to a race condition, it's not. Then, before you know it, the data is a mess.

Unique keys, foreign keys, check constraints, and DDL changes were all meant to solve real problems. I guess some apps might not benefit as much, but it seems like asking for trouble.

Given how easy it is to just use postgres, why invite all the risk?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#260

Post by VWWHFSfQ »

ricklepick wrote: post #228
nailer wrote: post #206

Earlier quoted context omitted.

New license that's not OSS (MongoDB Inc saying it is doesn't make it so, the OSD determines OSS, not some company).

The upstream project has been pretty vocal about their reasons to switch, and it's not because of the license. MongoDB just isn't the right tool for their use case, despite valiant attempts to utilize it.

This is very clearly because of licensing.
Post reply on HN