Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Squeeze the hell out of the system you have

blog.danslimmon.com

Post reply on HN
Print view View original

91–100 of 383 posts

Re: Squeeze the hell out of the system you have

#91

Post by whatshisface »

xapata wrote: post #78
roughly wrote: post #72

Earlier quoted context omitted.

Rumsfeld's got some great quotes, most of which were delivered in the context of explaining how the Iraq war turned into such a clusterfuck, and boy could that whole situation have used the kind of leadership Donald Rumsfeld's quotes would lead you to believe the man could've provided.

> could've If someone is 83.7% likely to provide good leadership, how would you evaluate the choice to hire that person as a leader in the hindsight that the person failed to provide good leadership -- was it a bad choice, or was it a good choice that was unlucky? (Likelihood was selected arbitrarily.)

>quotes would lead you to believe

Re: Squeeze the hell out of the system you have

#92

Post by thfuran »

roughly wrote: post #87
munificent wrote: post #79

Earlier quoted context omitted.

> An awful lot of postmortems I've been a part of have come down to "It didn't occur to us that could happen." Would that not be an unknown unknown?

Usually there's a tacit assumption of how the system works, how the users are using the system, or something else about the system or the environment that causes that - it's not that the answer wasn't known, it's that it was assumed to be something it wasn't and nobody realized that was an assumption and not a fact.

That's just an unknown unknown masquerading as a known known.

Re: Squeeze the hell out of the system you have

#93

Post by i_like_apis »

endisneigh wrote: post #6

The bit on the database performance issues leads me to my hottest, flamiest take for new projects: - Design your application's hot path to never use joins. Storage is cheap, denormalize everything and update it all in a transaction. It's truly amazing how much faster everything is when you eliminate joins. For your ad-hoc queries you can replicate to another database for analytical purposes. On this note, I have mixe…

Yes I like the zero joins on hot paths approach. It can be hard to sell people on it. It’s a great decision for scaling though.

Re: Squeeze the hell out of the system you have

#94

Post by walterbell »

tedunangst wrote: post #80
i_like_apis wrote: post #34

I’m reminded of one of my favorite sayings: You go to war with the army you have, not the army you might want or wish to have at a later time. You may want to ignore that this this comes from Donald Rumsfeld (he has some great ones though: “unknown unknowns …”, etc.) I think about this a lot when working on teams. Everyone is not perfectly agreeable or has the same understanding or collective goals. Some may be subop…

Mattis "the enemy gets a vote" is another good reminder of reality, although people get very angry about it. Useful in terms of security, privacy, DRM, etc.

Product management outside the box.

Re: Squeeze the hell out of the system you have

#95

Post by clintonb »

PeledYuval wrote: post #65
sheepz wrote: post #16

Agree wholeheartedly with the conclusion of the article. But the post makes it seem that there was no real query-level monitoring for the Postgres instance in place, other than perhaps the basic CPU/memory ones provided by the cloud provider. Using an ORM without this kind of monitoring is sure way to shoot yourself in the foot with n+1 queries, queries not using indexes/missing indexes etc The other thing that is am…

What's your recommended way of implementing this in a simple App Server Postgres architecture? Is there a good Postgres plugin or do you utilize something on the App side?

We use Datadog, which centralizes logs and application traces, allowing us to better pinpoint the exact request/code path making the slow query.

Re: Squeeze the hell out of the system you have

#96

Post by walterbell »

taylodl wrote: post #66
endisneigh wrote: post #6

The bit on the database performance issues leads me to my hottest, flamiest take for new projects: - Design your application's hot path to never use joins. Storage is cheap, denormalize everything and update it all in a transaction. It's truly amazing how much faster everything is when you eliminate joins. For your ad-hoc queries you can replicate to another database for analytical purposes. On this note, I have mixe…

My hot take: always use a materialized view or a stored procedure. Hide the actual, physical tables from the Application's account! The application doesn't need to know how the data is physically stored in the database. They specify the logical view they need of the data. The DBAs create the materialized view/stored procedure that's needed to implement that logical view. Since the application is never directly access…

Interface contracts and indirection FTW.

2011, "Materialized Views" by Rada Chirkova and Jun Yang, https://dsf.berkeley.edu/cs286/papers/mv-fntdb2012.pdf

> We cover three fundamental problems: (1) maintaining materialized views efficiently when the base tables change, (2) using materialized views effectively to improve performance and availability, and (3) selecting which views to materialize. We also point out their connections to a few other areas in database research, illustrate the benefit of cross-pollination of ideas with these areas, and identify several directions for research on materialized views.

Re: Squeeze the hell out of the system you have

#97

Post by alfalfasprout »

The problem is this is also a myopic way of looking at things. What you should be looking at is also operational complexity. What's the current burden on your org/team maintaining what you currently have? What about when you need to scale even higher?

A lot of teams that think this way end up with really high oncall burdens and then never have the time to even iterate on their infrastructure.

Re: Squeeze the hell out of the system you have

#98

Post by Buttons840 »

i_like_apis wrote: post #34

I’m reminded of one of my favorite sayings: You go to war with the army you have, not the army you might want or wish to have at a later time. You may want to ignore that this this comes from Donald Rumsfeld (he has some great ones though: “unknown unknowns …”, etc.) I think about this a lot when working on teams. Everyone is not perfectly agreeable or has the same understanding or collective goals. Some may be subop…

I like a similar quote from Steven Pressfield:

“The athlete knows the day will never come when he wakes up pain-free. He has to play hurt.”

This applies to ourselves more than our systems though.

Re: Squeeze the hell out of the system you have

#99

Post by a_seattle_ian »

KnobbleMcKnees wrote: post #56
i_like_apis wrote: post #34

I’m reminded of one of my favorite sayings: You go to war with the army you have, not the army you might want or wish to have at a later time. You may want to ignore that this this comes from Donald Rumsfeld (he has some great ones though: “unknown unknowns …”, etc.) I think about this a lot when working on teams. Everyone is not perfectly agreeable or has the same understanding or collective goals. Some may be subop…

That was Donald Rumsfeld!? I always assumed this came from some techie or agile guru given how much it's used as a concept in project planning.

That it came from Donald Rumsfeld in the context of what we know now and what he surely knew then is why it's such a good quote. The words basically say nothing but are also true about everything. So it can implicit be a warning that there is probably some bullshit going on or someone has a sense of humor and is also warning people while also avoiding the subject - of course just my opinion. How people actually use it will depend what the audience agrees it to mean.

Re: Squeeze the hell out of the system you have

#100

Post by walterbell »

sainez wrote: post #68
endisneigh wrote: post #28

Earlier quoted context omitted.

this has opinionated answers. if you ask Amazon, they might suggest that you design around a single table ( https://aws.amazon.com/blogs/compute/creating-a-single-table... ). in my opinion it's easier to use join tables. which are what are sometimes temporarily created when you do a join anyways. in this case, you permanently create table1, table2, and table1_join_table2, and keep all three in sync transactionally. w…

> what this might mean in practice is that you do mockups of all of the expected pages and what data is necessary on each one. then you design a schema that results in you never having to do joins on the majority, if not all, of them. Great suggestion! I had a role where I helped a small team develop a full stack, data-heavy application. I felt pretty good about the individual layers but I felt we could have done a b…

2001, "Denormalization effects on performance of RDBMS", by G. L. Sanders and Seungkyoon Shin, https://www.semanticscholar.org/paper/Denormalization-effect...

> We have suggested using denormalization as an intermediate step between logical and physical modeling, to be used as an analytic procedure for the design of the applications requirements criteria ... The guidelines and methodology presented are sufficiently general, and they can be applicable to most databases ... denormalization can enhance query performance when it is deployed with a complete understanding of application requirements.

PDF: https://web.archive.org/web/20171201030308/https://pdfs.sema...

Post reply on HN