News for hackers. Stuff that matters.

A comment on Scaling to 100M: MySQL Is a Better NoSQL. Parent comment

Re:Scaling to 100M: MySQL Is a Better NoSQL by koolba on Tuesday May 24, 2016 @07:32PM (#11766458)
> 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/

[ Parent | on HN ]
Re:Scaling to 100M: MySQL Is a Better NoSQL by spotman on Tuesday May 24, 2016 @07:37PM (#11766489)
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.

[ Parent | on HN ]
Re:Scaling to 100M: MySQL Is a Better NoSQL by koolba on Tuesday May 24, 2016 @07:57PM (#11766613)
> 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.

[ Parent | on HN ]
Re:Scaling to 100M: MySQL Is a Better NoSQL by jdiscar on Tuesday May 24, 2016 @09:07PM (#11766922)
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.

[ Parent | on HN ]
Re:Scaling to 100M: MySQL Is a Better NoSQL by manigandham on Tuesday May 24, 2016 @10:23PM (#11767254)
Actually yes, a single key-value database could handle all of their load with better functionality. Make that 2 nodes and you have HA and redundancy.

Problem solved.

[ Parent | on HN ]
Re:Scaling to 100M: MySQL Is a Better NoSQL by jbergens on Wednesday May 25, 2016 @03:39AM (#11768237)
I think you loose flexibility with sql. If the usage changes slightly and you need to index one or two more fields you would have to do an alter table and read through 200 GB of data deserializing all blobs to put the values into the new field. A good nosql would just add a secondary index. You might also have a hard time doing map-reduce on sql. It is often built into nosql systems.
[ Parent | on HN ]
Re:Scaling to 100M: MySQL Is a Better NoSQL by johanneskanybal on Wednesday May 25, 2016 @03:16AM (#11768162)
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.

[ Parent | on HN ]
Re:Scaling to 100M: MySQL Is a Better NoSQL by tremon on Wednesday May 25, 2016 @03:37PM (#11772462)
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.

[ Parent | on HN ]