You sound like someone who would throw their child's painting away instead of putting it on the fridge because it was just a piece of paper with a few brushes of paint slapped onto it.
WHAT LOL. You're on hacker news and you're complaining that people are hacking?! Literally the entire tenet is playing around and experimenting for our own edification and fun. On August 25, 1991, Linus Torvalds posted a message on the comp.os.minix newsgroup... something to the effect of "just a hobby, won’t be big and professional". I MEAN COME ON MR HACKER_NEWZ. The irony is deafening.
If the only explanation someone can provide is that "a cluster is slow", the issue isn't with network observability. They need to do at least the minimum level of analysis before escalating.
Yes, that would be great, but unfortunately there are application teams (particularly in the enterprise) lacking such tact when blaming infrastructure for issues.
Good old silos are alive and well, and ownership is not always part of the culture.
In our case the expected golden path is that once our team figures the proper procedure, we will establish it for the downstream teams that are direct supports of the application teams.
So at least in theory things are somewhat well set up, but there's too much siloing at our level (wildly separate network teams, teams for specific clouds, etc.)
Because database, in Postgres terms, doesn’t mean physical node. It’s more akin to a VM than anything else. The term for an installation of Postgres is database cluster, which can contain N databases, each of which can contain M schemas.
Thanks! Is there a good primer to this terminology that clarifies these terms on various popular database and cloud platforms?
It seems there is good potential for confusion unless we use the same terms consistently when discussing architecture and design across teams.
Even the term RDS (Relational Database Service) is sometimes said to be inaccurate since it is a "Relational Database SERVER as a Service"
A few related terms that cause confusion:
"Schema" could refer to a Database Schema or in some contexts, a single table's logical data structure. (Or a single data set's data structure -- or a standard for one, like JSON Schema)
Data Catalog products like "AWS Glue Data Catalog" which only store the metadata or schemas of the table they crawl ... refer to the entities they store as "Databases" and "Tables" (but no "Schemas") and documentation includes guides talk about "creating a database"[1] and "creating a table"[2] in AWS Glue. There has to be a better way to refer to all these entities without using the word schema with so many meanings -- or calling both physical tables and their metadata as "tables". Otherwise this is needlessly confusing and hard for beginners.
---
EDIT: even more madness. This StackOverflow discussion [3] has more examples of confusing usage:
> On Oracle .... A Schema is effectively a user. More specifically it's a set of tables/procs/indexes etc owned by a user. Another user has a different schema (tables he/she owns) however user can also see any schemas they have select priviliedges on.
Not AFAIK. In MySQL, the only time “cluster” is used is to refer to NDB Cluster, which is a distributed DB product. Schema means a logical grouping of tables, the same (more or less) as Postgres.
As to schema itself, yes, it’s heavily overloaded, and you just to grok it from context. I can talk about a table’s schema or a DB’s schema, or as you mentioned, JSON schema. Although the latter is helped by simply not using JSON in a relational DB.
You must remember that SQL is an ancient language, and the relational model is even older. There are going to be oddities.
Interesting projects. Pushing your code to a billion users. TC in the $500k-$1MM range.
I would really encourage people that don't mind big companies to study for the interviews and just get the job. I promise you that you'll someday run into the algorithms questions you studied in real life. And you'll grow your software engineering career and make a lot of money. Dismissively writing it off feels cool, but you're really missing out on a good experience.
(I don't work for a FAANG anymore, but I did once, and it was fun. Super smart coworkers. Interesting work. Great pay.)
Not unless you managed to get hired as a (quant) trader with a performance fee. Privatized gains, shared losses. Of course, it's very hard to get hired for such a role.
I have a ton of friends in finance. Many worked for the most prestigious IB firms out of undergrad and moved on to PE/hedge funds where they make mountains of cash. I don't know 1 of them who has even considered retiring anywhere close to 35, nor of anyone in their professional networks who've done so. Not saying its impossible but the likelihood of doing so is vanishingly small.
