zxc
Red Hat Satellite to standardize on PostgreSQL backend
141–150 of 298 posts
Re: Red Hat Satellite to standardize on PostgreSQL backend
#142Earlier 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…
XzXzXZXX
Re: Red Hat Satellite to standardize on PostgreSQL backend
#143Earlier 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…
> Pretty much all of the things you'd want in a relational database are now present in Mongodb too.
On the "relational" front, it has denormalized-only schema validation and limits transactions to replica sets (so no transactions with sharding), while also recommending single-document transactions over multi-document transaction via denormalization. (FWIW, transactions aren't available in any open source release).
On the "database" front, it has a history of misleading users and remorselessly dropping data.
> Postgres will get you pretty far
Postgres is an actual relational database, open source, battle-proven with a good design and a great team behind it. It never claimed to be good at, let alone capable of, doing things it could not actually do (well, or at all).
> but beyond a certain point the scaling story breaks down and you have to hack some sort of user space sharding solution.
Scaling IS a hard thing, and presents itself quite differently to different use-cases. Nevertheless, horizontally scaling Postgres — for when one truly hits the petabyte-scale — is a problem that has been solved correctly many times before (out of core). For a similar-to-MongoDB method, check out Citus, with the assurance that it only adds to an actual database; as opposed to the MongoDB way of doing things: make up and promise magic scaling solutions that "Just Work", then try to build a database on top of it.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#144Earlier 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…
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?
Would you use Postgres for developing something like, say, iTunes? I’d think SQLite would be a much more “natural” fit there.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#145Earlier quoted context omitted.
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?
I think is more complex than that, when you modify some data structure in memory you also want write to disk immediately as to not lose any data in case of a crash, so this means to write the new file under a separate name and then renaming the new file to replace the old file only after it has been successfully written as to provide safety against storage corruption. I wouldn't recommend this to a beginner, the sqli…
> this means to write the new file under a separate name and then renaming the new file to replace the old file only after it has been successfully written as to provide safety against storage corruption
I agree, that's about the only bit of complexity in all this. But it's completely generic, so it can be made into a small library, and then reused without dealing with the complexity every time. For example:
Re: Red Hat Satellite to standardize on PostgreSQL backend
#146Earlier 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,…
Looking around the office and my phone, Java is anything but "legacy". As for alternative JVM languages, while they are cool and have brought many fresh ideas into the platform, they remain a very tiny portion of the Java developers' market. Java takes a very long time, because backwards compatibility and cooperation among giant companies takes years. C# has basically Microsoft deciding how the roadmap looks like and…
And yet Google is investing into Kotlin.
Yes, Java takes it slow because its target market - enterprises - want it, and they have good reason to. There's nothing wrong with that. All I'm saying is that there are many other niches where developers find lagging too far behind other available options, and there's a noticeable decline in its use because of that.
And so the analogy with PostgreSQL in this case isn't working well.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#147Earlier quoted context omitted.
There were single script 1-click installs for it in bash all over for me..but yeah jvm is a hog.
My experience with those one-liner installs is that they usually work ... strictly speaking. They don't scale, they don't deal with edge cases, they know nothing of your environment. They install one piece of software (in an "interesting" way that won't upgrade), and that's it.
My last pay check was $9500 working 12 hours a week online. My sisters friend has been averaging 15k for months now and she works about 20 hours a week. I can't believe how easy it was once I tried it out. This is what I do,
HERE►► http://www.worktoday33.com
Re: Red Hat Satellite to standardize on PostgreSQL backend
#148Earlier quoted context omitted.
There were single script 1-click installs for it in bash all over for me..but yeah jvm is a hog.
My experience with those one-liner installs is that they usually work ... strictly speaking. They don't scale, they don't deal with edge cases, they know nothing of your environment. They install one piece of software (in an "interesting" way that won't upgrade), and that's it.
ZZ
Re: Red Hat Satellite to standardize on PostgreSQL backend
#149Earlier 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.
That was just Java doing Java things. Business as usual.
This is a nonsense comment doing language troll things.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#150Earlier 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
I've rarely seen a codebase outlive it's database, but I constantly see databases survive through multiple codebases.