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

31–40 of 383 posts

Re: Squeeze the hell out of the system you have

#31

Post by latchkey »

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…

> Design your application's hot path to never use joins.

Grab (uber of asia) did this religiously and it created a ton of friction within the company due to the way the teams were laid out. It always required one team to add some sort of API that another team could take advantage of. Since the first team was so busy always implementing their own features, it created roadblocks with other teams and everyone started pointing fingers at each other to the point that nothing ever got done on time.

Law of unintended consequences

Re: Squeeze the hell out of the system you have

#32

Post by endisneigh »

Bognar wrote: post #30
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…

Denormalized transactions are not trivial unless you are using serializable isolation level which will kill performance. If you don't use serializable isolation level, then you risk either running into deadlocks (which will kill performance) or inconsistency. Decent SQL databases offer materialized views, which probably give you what you want without all the headache of maintaining denormalized tables yourself.

all fair points, but to be fair I don't necessary think this makes the most sense for an existing project for the reasons you state. I do think for a new project would best be able to design around the access patterns in a way that eliminate most of the downsides.

Re: Squeeze the hell out of the system you have

#33

Post by endisneigh »

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

> Design your application's hot path to never use joins. Grab (uber of asia) did this religiously and it created a ton of friction within the company due to the way the teams were laid out. It always required one team to add some sort of API that another team could take advantage of. Since the first team was so busy always implementing their own features, it created roadblocks with other teams and everyone started po…

yes, this is a fair point. there's no free lunch after all. without knowing more about what happened with Grab I'd say you could mitigate some of that with good management and access patterns, though.

Re: Squeeze the hell out of the system you have

#34

Post by i_like_apis »

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 suboptimal or prone to doing things you don’t prefer. But having a team is better than no team, so find the best way to accomplish goals with the one you have.

It applies to systems well too.

Re: Squeeze the hell out of the system you have

#35

Post by javajosh »

Xeoncross wrote: post #5

> The real cost of increased complexity – often the much larger cost – is attention. ...or just mental load. I'm tired of working on micro-service systems that still have downtime, but no one knows how it all works. Most are actually just distributed monoliths so changes often touch multiple services and have to be rolled out in order. Data has to be duplicated, tasks have to be synchronized, state has to be shared,…

This is a very common architectural smell, when you have uservices and "no-one knows how they all work". The whole point is that no-one can or should know how they all work; the fact that someone does in order to fix or modify the system is a strong signal that you've violated some of the rules - like single responsibility, and proper abstraction through API. But, in my experience, this is extremely common - debugging a pipeline of N microservices often requires running and building all N services locally. This is, strictly speaking, a monolith + network partitions + (infinite) build/deploy variation. An extremely challenging work environment that is ultimately beyond any mortal programmer's ability, IMO.

Re: Squeeze the hell out of the system you have

#37

Post by WallyFunk »

> Of course, I’m not saying complexity is bad. It’s necessary.

Weird thing about computers, even after a fresh install of your favorite OS, the whole thing is sitting on a mountain of complexity, and that's before you start installing programs, browse the web, etc

Only the die-hard use things like MINIX[0] to do their computing. Correction: MINIX is in the Intel Management Engine so you have /two/ computers.

[0] https://en.wikipedia.org/wiki/Minix

Re: Squeeze the hell out of the system you have

#38

Post by latchkey »

endisneigh wrote: post #33
latchkey wrote: post #31

Earlier quoted context omitted.

> Design your application's hot path to never use joins. Grab (uber of asia) did this religiously and it created a ton of friction within the company due to the way the teams were laid out. It always required one team to add some sort of API that another team could take advantage of. Since the first team was so busy always implementing their own features, it created roadblocks with other teams and everyone started po…

yes, this is a fair point. there's no free lunch after all. without knowing more about what happened with Grab I'd say you could mitigate some of that with good management and access patterns, though.

All in all though, I don't think that 'never use joins' is a good solution either since it does create more developer work almost every way you slice it.

I think the op's solution of looking more closely at the hot paths and solving for those is a far better solution than re-architecting the application in ways that could, or can, create unintended consequences. People don't consider that enough, at all.

Don't forget that hot path resolution is the antithesis of 'premature optimization'.

> you could mitigate some of that with good management and access patterns

the CTO fired me for making those sorts of suggestions about better management, and then got fired himself a couple months later... ¯\_(ツ)_/¯... even with the macro events, their stock is down 72% since it opened, which doesn't surprise me in the least bit having been on the inside...

Re: Squeeze the hell out of the system you have

#39

Post by joshstrange »

iamwil wrote: post #22
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…

If you don't use joins, how do you associate records from two different tables when displaying the UI? Do you just join in the application? Or something else?

Single Table Design is the way forward here. I can highly recommend The DynamoDB Book [0] and anything (talks, blogs, etc) that Rick Houlihan has put out. In previous discussions the author shared a coupon code ("HACKERNEWS") that will take $20-$50 off the cost depending on the package you buy. It worked earlier this year for me when I bought the book. It was very helpful and I referred back to it a number of times. This github repo [1] is also a wealth of information (maintained by the same guy who wrote the book).

As an added data point I don't really like programming books but bought this since the data out there on Single Table Design was sparse or not well organized, it was worth every penny for me.

[0] https://www.dynamodbbook.com/

[1] https://github.com/alexdebrie/awesome-dynamodb

Re: Squeeze the hell out of the system you have

#40

Post by joshstrange »

veave wrote: post #27
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…

>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. Anybody has documentation about this with examples?

See "Single Table Design" which I talked about in this comment above: https://news.ycombinator.com/item?id=37093357
Post reply on HN