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

161–170 of 383 posts

Re: Squeeze the hell out of the system you have

#161

Post by bmurphy1976 »

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 think about this whenever a product lead talks about planning something, dumping it on the dev team, and saying it's the dev team's responsibility to figure out how to implement it. No wonder the part of the company that does this has a very contentious relationship with their product team and is overly oriented around metrics, having to constantly fight for resources and prove they don't have the bandwidth to take on projects.

Meanwhile our side of the org has a much more collaborative relationship with our product team. We have our issues for sure, but our relationships are sound. The feedback loop is tight and product pushes back on things as much as the dev team does. Product works with the dev team to figure out what we can do and stays with us to the end. There's much less tossing things over the fence and everybody seems happier.

Re: Squeeze the hell out of the system you have

#162

Post by other_herbert »

xyzzy123 wrote: post #128
feoren wrote: post #115

Earlier quoted context omitted.

There are "tall" applications and "wide" applications. Almost all advice you ever read about database design and optimization is for "tall" applications. Basically, it means that your application is only doing one single thing, and everything else is in service of that. Most of the big tech companies you can think of are tall. They have only a handful of really critical, driving concepts in their data model. Facebook…

Thanks I think this is a really interesting way to look at things. What is the market for "wide" applications though? It seems like any particular business can only really support one or two of them, for some that will be SAP and for others it might be Salesforce (if they don't need much ERP), or (as you mentioned) some giant semi homebrewed Oracle thing. Usually there is a legacy system which is failing but still ru…

Lotus notes is wide… I imagine their scope creep checker was just a sticky note that said Absolutely!!

Re: Squeeze the hell out of the system you have

#163

Post by pixl97 »

wizofaus wrote: post #71
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…

Can't say I've ever come across a scenario where a join itself was the performance bottleneck. If there's any single principle I have observed is "don't let a table get too big". More often than not it's historical-record type tables that are the issue - but the amount of data you need for day-to-day operations is usually a tiny fraction of what's actually in the table, and you're bound to start finding operations on…

In enterprise clients you commonly run into issues where the company thinks you have to save all data forever. Very often this runs in a pattern where the application is lightly used a first then uptake increases over time. Then you run into the slowness issue. They typically expand DB sizing, bit eventually run into the problem where archiving is needed. This can be a huge problem when it's an after thought instead of a primary design. All kinds of fun when you have key relationships between different tablea.

Re: Squeeze the hell out of the system you have

#164

Post by roughly »

hluska wrote: post #110
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.

I like to remind myself that very few people reach positions of great power after mediocre lives. Rather there’s a thread of talent that runs through government. Once they’re in, the predilections that led to power often rear their dark long tails. But they’re all (even the ones I disagree with) talented.

Politics is fundamentally the art of convincing people of things - usually “vote for me.” That is the only skill that acquisition of high office is evidence of. Many politicians have more skills than just than that, but the mere fact of having acquired high office tells you nothing more about a person than that they’re particularly good at politics.

Re: Squeeze the hell out of the system you have

#165

Post by sgarland »

killjoywashere wrote: post #108
KnobbleMcKnees wrote: post #56

Earlier quoted context omitted.

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.

As a military officer who was watching CNN live from inside an aircraft carrier (moored) when he said that, being in charge of anti-terrorism on the ship at the time, it was absolutely foundational to my approach to so many things after that. Here's the actual footage: https://www.youtube.com/watch?v=REWeBzGuzCc Rumsfeld was complicated, but there's no doubt he was very effective at leading the Department. I think mo…

> Google's hallowed SRE system was developed by an engineer who had come up through the ranks of Navy nuclear power

Wait, really? That makes _so much sense._ It also makes me upset that all of my attempts to sway other SRE orgs over to Nuclear Navy practices have been met with doubt.

- ex nuke submariner

Re: Squeeze the hell out of the system you have

#166

Post by lanstin »

other_herbert wrote: post #162
xyzzy123 wrote: post #128

Earlier quoted context omitted.

Thanks I think this is a really interesting way to look at things. What is the market for "wide" applications though? It seems like any particular business can only really support one or two of them, for some that will be SAP and for others it might be Salesforce (if they don't need much ERP), or (as you mentioned) some giant semi homebrewed Oracle thing. Usually there is a legacy system which is failing but still ru…

Lotus notes is wide… I imagine their scope creep checker was just a sticky note that said Absolutely!!

I miss notes - it was really a better way to organize companies than anything later. Historical valuable data, records of why decisions were made, ephemeral email like things but for groups, user programmable if it didn't quite match your needs, robust encryption, it had it all.

Re: Squeeze the hell out of the system you have

#167

Post by r00fus »

DylanDmitri wrote: post #152
feoren wrote: post #115

Earlier quoted context omitted.

There are "tall" applications and "wide" applications. Almost all advice you ever read about database design and optimization is for "tall" applications. Basically, it means that your application is only doing one single thing, and everything else is in service of that. Most of the big tech companies you can think of are tall. They have only a handful of really critical, driving concepts in their data model. Facebook…

For Amazon, if we consider everything for website retail purchases, I would estimate tens of thousands of table schemas. This is counting: - Sellers (Amazon, third party, retail store) - Inventory (forecasting, recommendation) - Customers (comments, ratings, returns, preferences) - Warehouses (5+ distinct types, filled with custom machines) - Transit Options (long haul, air, vans, cars, bikes, walking, boats) - Deliv…

But these aren't the website, right? Amazon runs "wide" enterprise systems in the back end for sure.

Re: Squeeze the hell out of the system you have

#168

Post by pphysch »

tedunangst wrote: post #88
aidos wrote: post #55

Earlier quoted context omitted.

Interestingly, I often ask candidates about optimising a slow running db query and the majority of people jump to adding caching and very few ask if they can run an explain or see the indexes.

"I would make the slow query faster" seems too obvious an answer for an interview question.

The question is usually phrased like "what would you check/do if you had a page that was taking many seconds to load".

Re: Squeeze the hell out of the system you have

#169

Post by lanstin »

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…

That's how it was at AOL. But also, in general, people who wrote C code never designed SQL stuff. We'd come up with some requirements, meet with a DBA (who at the time got paid a lot more money, I always assumed because their work was inherently dull), they'd put together stored procedures for use to call, and then do whatever on the physical table side. They did sometimes change the physical table stuff without us having to change anything (not sharding tho, that was edit a TCL file and restart when they said to restart).

Re: Squeeze the hell out of the system you have

#170

Post by sgarland »

williamdclt wrote: post #61
endisneigh wrote: post #18

Earlier quoted context omitted.

Yes, but I assert that it's possible to use transactions to update everything consistently. Serializable transactions weren't really common when MySQL/Postgres first came out, but now that they're common in new DBs + ACID, I think it's not possible to do with reasonable difficulty. If you agree with this, than its easy to prove that denormalized tables performance increase is well worth the annoyance of updating ever…

Transactions are not only (actually mainly not) about atomicity. Of course it’s possible to keep data integrity without normalisation, but that means you need to maintain the invariants yourself at application level and a big could result in data inconsistency. Normalisation isn’t there to make integrity possible, it’s there to make (some) non-integrity impossible. Nobody says you have to have only one view of your d…

> that means you need to maintain the invariants yourself at application level

Foreign Keys.

Of course, now you have a new set of problems, but referential integrity isn't one of them.

Post reply on HN