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

271–280 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#271

Post by kjeetgill »

manigandham wrote: post #163
eropple wrote: post #96

Earlier quoted context omitted.

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…

I rather be able to do something than be prevented because someone somewhere thinks that it's "potentially catastrophic". That seems especially hyperbolic in this case.

To each their own, but I can second that most Java programmers find that ability horrifying and if it came to a vote would probably get it ejected.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#272

Post by int_19h »

fauigerzigerk wrote: post #179
int_19h wrote: post #93

Earlier quoted context omitted.

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

I don't think the number of records is the right benchmark. The reason why data is better kept in a database system is because it often has a very different life cycle than applications. It often lives longer and gets used by more than one application. That's why modelling and storing data somewhat separately from applications often makes sense regardless of the amount of data you have. Also, procedural code is often…

> the reason why data is better kept in a database system is because it often has a very different life cycle than applications. It often lives longer and gets used by more than one application.

It sounds like you're thinking about web and enterprise apps that share data sources. For those, absolutely, use DBMS. You don't want to solve concurrency and consistency yourself.

I was talking more broadly, of apps of all kinds. Does a TODO list app for your phone need a DBMS? There's not going to be any concurrent data access there, nor huge amounts of data, nor complicated queries. But that describes most apps, and most of their data! Even for web apps, an exclusive data store is more common than shared (just think about all the WordPress blogs online!).

> Also, procedural code is often far more complicated than a SQL query regardless of the number of records being processed.

If your language doesn't have some kind of declarative query framework for sequences, you're probably better off with SQL. But these days, who doesn't have that? Even Java caught up.

(I'd single out C++/STL for offering non-composable primitives, until ranges get into the standard. But C++ is a wrong choice for a data-heavy app in general, IMO. )

Re: Red Hat Satellite to standardize on PostgreSQL backend

#273

Post by int_19h »

lowercased wrote: post #242
chrisseaton wrote: post #89

Earlier quoted context omitted.

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

> If so you can save yourself a lot of complexity. The complexity exists, you're just shifting it around some. The "complexity" of setting up a populate db server is non-zero, but generally a known-entity. The complexity of managing your own stuff 'in-memory', with all the attendant issues about concurrency/corruption/performance/etc - would almost always end up being far more custom to your particular project.

If that were true, we wouldn't store any data in memory at all - everything would be in the database to avoid "the attendant issues about concurrency/corruption/performance/etc".

But we don't. Perhaps because the attendant issues often aren't issues in practice? There's no concurrency problem if it's just your app working with data, and it's logically single threaded (i.e. possibly async, but serialized) - which is by far the most common model for non-web apps. There's also no concurrency problem if you use immutable data structures. There's no corruption problem if you are using a memory-safe language, and your data structures enforce their invariants, as they should in any good design regardless of anything else. Performance is going to be better, often significantly so, until you have enough data that dumb queries over it are slower than the overhead of communicating with the database. And so on.

So, no, the complexity doesn't necessarily exist. The complexity of your data is constant, and of the kind of processing that you need to do with it, true. But we're talking about complexity of the pipeline you use to access that data - and there, you can absolutely make it more complicated that it needs to be, and I'm arguing that it is what usually happens in practice.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#274

Post by emmanueloga_ »

bane wrote: post #31
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…

I once worked at a place that, at some point in the past, had developed some kind of semantic graph database that never gained market traction. The author of it had ended up as CTO and kept seeking out uses for his work and ended up finding all kinds of odd places for it to live, including as the auth database in a large scale document analytics system and running part of the payroll. We were constantly running into…

There aren't many of these databases around... Which database was that? is it still around?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#275

Post by int_19h »

manigandham wrote: post #162
pjmlp wrote: post #113

Earlier quoted context omitted.

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…

Runtimes are different from languages. The C# language has never been rebooted and is fully backwards compatible, and there's no better example of long-term support than Microsoft. You can still run apps from the MSDOS era, and even upgrade MSDOS through to Windows 10 if you have all the CDs today.

> The C# language has never been rebooted and is fully backwards compatible

This is not true - there have been several breaking changes in C#-the-language since 1.0. For example:

https://davefancher.com/2012/11/03/c-5-0-breaking-changes/

Re: Red Hat Satellite to standardize on PostgreSQL backend

#276

Post by int_19h »

kjeetgill wrote: post #271
manigandham wrote: post #163

Earlier quoted context omitted.

I rather be able to do something than be prevented because someone somewhere thinks that it's "potentially catastrophic". That seems especially hyperbolic in this case.

To each their own, but I can second that most Java programmers find that ability horrifying and if it came to a vote would probably get it ejected.

Do Java programmers find mutable variables in general horrifying? That was not my impression - certainly, the language doesn't make it easy to make everything immutable. If so, why the special distinction for lambdas?

The official rationale was that they expected lambdas to be mostly used for parallel sequence processing, and wanted to avoid race conditions. Of course, in practice, lambdas are very useful in many other places, where there's no concurrency issue at all - async continuation callbacks, for example, or pseudo-custom language constructs implemented as functions with a lambda for a body.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#277

Post by arendtio »

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?

I think the easiest way to do it wrong, is to close the file every time you finished your operation. With the default settings, this will sync and wait until the filesystem completes its operation. So unless you will close the file for a long time, keep it open. If you want to access the DB in a multi-threaded environment you better let one process manage the database.

I guess 90% or performance problems with SQLite come from the filesystem.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#278

Post by int_19h »

CydeWeys wrote: post #255
tim333 wrote: post #253

Earlier quoted context omitted.

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?

Depends on how many concurrent requests you have.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#279

Post by linkmotif »

chousuke wrote: post #237
linkmotif wrote: post #234

Earlier quoted context omitted.

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.

I find it very pleasant, but I also tend to avoid ORMs. I can just write SQL queries to get me the data I need in any form I want, and it's not always useful to stuff that into objects when I can just process it as is.

Processing data from format to format is a total drag to me. I just can't do it.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#280

Post by chrisseaton »

kjeetgill wrote: post #270
chrisseaton wrote: post #172

Earlier quoted context omitted.

What’s the memory model for captured variables being mutated by multiple threads?

Yea, that seems frightening. I like to think of my local variables as my inaccessible local state. I'd imagine it keeps my JIT happy too. What would it even mean to have a lambda reference to a variable who's stack frame has already popped?

> What would it even mean to have a lambda reference to a variable who's stack frame has already popped?

That bit is simple - the variable is kept alive as long as there is still a lambda that references it.

Don’t think about stacks - that’s an implementation detail and the compiler is free to use a combination of the stack and the heap to implement local variables.

The issue I’m talking about is if one thread writes a local and another reads it, what does that look like?

Post reply on HN