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

Scaling to 100M: MySQL Is a Better NoSQL

blog.wix.engineering

Post reply on HN
Print view View original

121–130 of 183 posts

Re: Scaling to 100M: MySQL Is a Better NoSQL

#121

Post by jdiscar »

koolba wrote: post #114
spotman wrote: post #112

Earlier quoted context omitted.

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.

> 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.

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.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#122

Post by jdiscar »

agentgt wrote: post #72
wvenable wrote: post #64

Earlier quoted context omitted.

To be fair, this article is about using MySQL as a NoSQL storage and so all of this advice is geared towards that use-case. I'd kill for so much traffic that any of this would be necessary as opposed to any RDBMS best-practices. I do agree that UUIDs should be stored differently -- the use of varchar rather than a fixed length type for a primary key will hurt performance.

We use varchar for UUID (on postgres) which surprisingly hasn't been that terribly performance wise. And yes we do use varchar(36) although on postgres it doesn't really matter because I think almost all varchars are text. I would love to switch to native UUID someday though.

Yeah, VARCHAR and TEXT are backed by the same datatype, but VARCHAR(N) gives you a limit check (that can be a pain to change if you ever need to.) There shouldn't be any noticable performance difference. For UUIDs, the native type is way better.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#124

Post by sjwright »

I've been running a rather large website with MySQL for the past fifteen years. There was a period when I regretted that choice and used something else. Today I'm using MariaDB and the TokuDB storage engine, and I'm so thankful that I never migrated to Postgres.

Like many people I investigated the NoSQL movement for potential applicability, and almost swallowed the hype. As I investigated more, I realised:

1. There are some specific instances where a NoSQL engine makes good sense. They're a valid option and should be considered depending on the application. In my experience though, well formed RDBMS structures are the better option in the vast majority of applications.

2. Most of the hype and growth came from people who (a) were using the abomination known as ORMs which are the canonical example of a round peg in a square hole; and/or (b) didn't know how to build performant RDBMS schemas. For these people, the NoSQL engine was fast because it was the first engine they actually learned how to optimise correctly.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#125

Post by wainstead »

sjwright wrote: post #124

I've been running a rather large website with MySQL for the past fifteen years. There was a period when I regretted that choice and used something else. Today I'm using MariaDB and the TokuDB storage engine, and I'm so thankful that I never migrated to Postgres. Like many people I investigated the NoSQL movement for potential applicability, and almost swallowed the hype. As I investigated more, I realised: 1. There a…

> were using the abomination known as ORMs which are the canonical example of a round peg in a square hole

Indeed, the "Vietnam of computer science."

https://blog.codinghorror.com/object-relational-mapping-is-t...

Re: Scaling to 100M: MySQL Is a Better NoSQL

#126

Post by tagrun »

koolba wrote: post #56

So much to disagree with here ... > Locks limit access to the table, so on a high throughput use case it may limit our performance. Then use a proper database that implements MVCC. > Do not use transactions, which introduce locks. Instead, use applicative transactions. Or just use a database that handle transactions more efficiently. > `site_id` varchar(50) NOT NULL, Why varchar(50)? UUIDs are 16-bytes. The best way…

>> `site_id` varchar(50) NOT NULL,

> Why varchar(50)? UUIDs are 16-bytes.

Why do you think it's a UUID?

> The best way to store them would be the binary bytes (which is how postgres stores them).

Is it actually better than a pair of BIGINTs?

Re: Scaling to 100M: MySQL Is a Better NoSQL

#127

Post by TylerE »

odonnellryan wrote: post #109
TylerE wrote: post #33

Earlier quoted context omitted.

By 'a bunch of things' you mean uncomment like 2 lines in the config, right?

Well, he's right about it, kinda. I don't have problems with Postgres, but I do wish it had some defaults that made a bit more sense.

I think the defaults make a fair bit of sense. Do you want it listening on a network interface by default?

Re: Scaling to 100M: MySQL Is a Better NoSQL

#129

Post by manigandham »

jdiscar wrote: post #121
koolba wrote: post #114

Earlier quoted context omitted.

> 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.

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.

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.

Re: Scaling to 100M: MySQL Is a Better NoSQL

#130

Post by giaosudau »

adenverd wrote: post #128

100M? Of course you'd scale an RDBMS for that, especially if you want searchability and analytics. It's way easier than a Hadoop -> Elasticsearch pipeline (or pick your flavor). NoSQL databases are for BIG data. As in, billions of rows big.

totally agree with that. 100M rows doesn't make any sense.
Post reply on HN