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

91–100 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#91

Post by HillRat »

Bucephalus355 wrote: post #6
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?

Wow was MongoDB really that bad?

Generally, if you’re going to standardize on a single data repository, a traditional RDBMS will be a better fit than a NoSQL solution, unless you really need polymorphic capabilities and have a document-centric conceptual model (such as a CMS or certain kinds of contact center solutions). So this is really less about MongoDB being bad than relational being more appropriate.

MongoDB has definitely come a long way from when they were dropping writes and hitting scaling limits, and their new tools ecosystem holds a lot of promise, but I treat them much like any other non-RDBMS store (Redis, Cassandra, Neo4J...) in that they’re very specific tools for specific needs, not something that can be kit-bashed for any general class of problem.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#92

Post by krferriter »

unethical_ban wrote: post #70
bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

Compelling reason #1: We don't need hot-warm HA and don't want to fight for a database with IT every time we write a homebrew app. We use SQLite.

If you're writing apps for user computers that have no reason to sync to a central remote database then SQLite is totally fine. If you're writing an application that runs in a cluster or on the web, Postgres is the way to go. There almost never a reason to go with Mongo unless you're just trying to get buzzwords in a presentation and trying to seem hip. That's going away now though. My place exclusively uses Postgres on all of our webservers.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#93

Post by int_19h »

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?

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 using an ORM or something similar - it's still unneeded complexity, if you don't have too many users.

Think of it from the opposite perspective - if you can work directly with in-memory data, why would you prefer to run SQL queries instead? The latter is obviously more complex, but what's the advantage? There are many valid cases that have a good answer to that question, but there are many more that don't.

I can't help but think that we're conditioned to use DBMS (SQL or not) largely by inertia. When we learn about them, the examples are necessarily toy ones - tables with a dozen of records, that sort of thing. But one side effect is that it subtly normalizes the notion that this much data warrants a dedicated DBMS - so people don't balk at even patently ridiculous setups, like a separate SQL server used to hold a grand total of a couple thousand records in all its tables (this is a real thing, something that I personally did in a LOB app many years ago; I didn't have a good justification, it was pure cargo cult, and the app could have done everything it did in-memory, faster, and easier to code).

And sometimes, when you ask, people say, "yeah, it's only 1000 records now, but we're going to grow later, and then we'll need a DBMS". But you'd need to grow by many orders of magnitude to get there - and if you get that opportunity, you'll also have the resources to adapt. But everybody dreams of being Google.

And then you have apps like, say, a todo list manager app. Is it ever going to deal with millions of todo records? I don't think so. Then why does it need an SQLite DB?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#94

Post by cutety »

d4l3k wrote: post #58
MBCook wrote: post #12

Earlier quoted context omitted.

From reading the post it sounds like they want transactions for some of the functionality they’re trying to build. I guess Mongo still doesn’t have those.

They recently added multi document transactions though. https://docs.mongodb.com/manual/core/transactions/

This may just be my bias against NoSQL (I’ll qualify this with I don’t believe it should never be used, but 90% of use cases psql/MySQL/etc is likely the better choice these days), but when it comes to choosing a DB engine when you want ACID transactions, I’d pick the one that was built to handle ACID transactions from the start, rather than one that just added it with this large caveat in the middle of the docs:

> In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transaction should not be a replacement for effective schema design. For many scenarios, the denormalized data model (embedded documents and arrays) will continue to be optimal for your data and use cases. That is, for many scenarios, modeling your data appropriately will minimize the need for multi-document transactions.

So, to be able to have one of the core features of SQL, you lose the biggest feature of NoSQL which is super fast writes. Which, they try to remind you that if you model your data in correctly, by creating denormalized documents with embedded data, you probably won’t need them anyway. Which just makes me cringe at having to maintain these huge unstructured documents just so you get faster writes since you don’t have to worry about ACID.

Or, you can use Postgres, which was built with ACID from the start, using technology and design patterns proven over decades, and has support for JSONB if you need unstructured/document storage that you can also (fairly) efficiently query.

Maybe I’m just woefully uninformed, but I just can’t imagine a use case for Mongo unless your dealing with Google level data/traffic, and fortunately in their case, they have enough money to hire enough people that actually know how & when to use Mongo effectively to the point that it’s not just a fancy way to write to /dev/null.

I’d actually be really interested in some non-Google scale use cases for Mongo, like where Postgres’ performance was actually an issue, and how much Mongo actually outperforms it, and the trade offs/issues switching. Most posts I’ve seen are of the opposite migration, but I want to see what all the hype for a DB engine (what I’ve always saw as one of the less _sexy_ areas of CS, at least in marketability, compared to ML/AI or Programing Language/Compilers)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#95

Post by fred_is_fred »

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?

"Web scale"

Re: Red Hat Satellite to standardize on PostgreSQL backend

#96

Post by eropple »

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.

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 so potentially catastrophic and difficult to debug is an odd one.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#97

Post by fyfy18 »

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…

It sounds more like an edge case though. I can't imagine all the data you need to store may or may not be the right format, so I wouldn't switch my database just because one or two entities need this.

Anyway this is 2019 so PostgreSQL JSONB fields have got you covered. You can even efficiently query the JSON objects within them.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#98

Post by kevinmgranger »

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…

For most languages and frameworks, using Postgres as opposed to sqlite is barely a higher cost if you’ve got the ops skills. I’ve yet to see an app that straddled this local/web-scale line where SQLite was a better choice or Postgres wasn’t the obvious choice.

There isn’t some massive cost to using Postgres instead, is there some desktop divide I’m missing here?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#99

Post by cobythedog »

cutety wrote: post #94
d4l3k wrote: post #58

Earlier quoted context omitted.

They recently added multi document transactions though. https://docs.mongodb.com/manual/core/transactions/

This may just be my bias against NoSQL (I’ll qualify this with I don’t believe it should never be used, but 90% of use cases psql/MySQL/etc is likely the better choice these days), but when it comes to choosing a DB engine when you want ACID transactions, I’d pick the one that was built to handle ACID transactions from the start, rather than one that just added it with this large caveat in the middle of the docs: > I…

...

Re: Red Hat Satellite to standardize on PostgreSQL backend

#100

Post by thomaslangston »

int_19h wrote: post #77
sonnyblarney wrote: post #57

Earlier quoted context omitted.

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…

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.

Post reply on HN