undefined | Better HN

0 pointskoolba10y ago0 comments

> Of course it flies in the face of best practice for running a smaller system. Is there tradeoffs? Absolutely! Would it be smart to do this if the need for this scale is not obvious? Probably not

From the article:

> The routes table is of the order of magnitude of 100,000,000 records, 10GB of storage. > The sites table is of the order of magnitude of 100,000,000 records, 200GB of storage

That's tiny. Both of those easily fit in memory on modern hardware. This isn't cough web scale, this is peanuts.

The savings from having a simpler system that operates both transactional and the lack of disparate CASE/IF logic would win over this monstrosity of a design.

For a counterpoint where this type of model makes more sense check out Ubers data model[1]. Similar setup but more applicable use case and (without having any inside intel on it) I'd wager is justified.

[1]: https://eng.uber.com/schemaless-part-one/

0 comments

5 comments · 2 top-level

spotman10y ago· 2 in thread

So your argument has shape shifted from "This is terrible advice" to "this is terrible advice unless your at uber scale".

Sounds like we are in agreement then - at high enough scale - this is solid advice.

koolbaOP10y ago

> So your argument has shape shifted from "This is terrible advice" to "this is terrible advice unless your at uber scale".

No my argument is this particular design is both unjustified for the use case and poorly thought out/implemented. The uuid as varchar(50) is a dead giveaway of amateur status.

jdiscar10y ago

Are you saying a NoSQL solution is better for this use case? Because that's what this article is asking. Sure, they could do things better (can't we always?), but that's not the point they're trying to make.

Like you said, 10GB of data isn't very much, it really doesn't matter if you go with NoSQL or SQL. But SQL will probably give you more flexibility and will be easier to manage until you get really, really big.

2 more replies

johanneskanybal10y ago· 1 in thread

Not sure how you manage to miss the point of the article. I'll break it down for you:

* A lot of traditional sql solutions have scaling issues.

* A lot of nosql solutions for these issues have become popular in recent years. Their main use case is web scale (simplification)

* A ton of actual use cases fall between those two chairs i.e they would have scaling issues with traditional sql systems but don't really have billions of transactions to process.

The article presents some valid real world approaches for this third case, some of it might be case dependant but overall pretty good advice.

tremon10y ago

they would have scaling issues with traditional sql systems but don't really have billions of transactions to process.

If you have scaling issues with traditional SQL systems, the first thing you should do is understand your problem, not cargo-cult to a different paradigm.

More specifically:

* You do not get to complain about SQL transaction speed if you use denormalized tables.

* You do not get to complain about SQL transaction speed if your primary keys are varchar(50).

* You do not get to complain about SQL transaction speed if you store all non-identifying data in a single json blob.

j / k navigate · click thread line to collapse