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

161–170 of 183 posts

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

#161

Post by return0 »

jjoe wrote: post #36

Scalability is like an abstract painting. It's unique to one's infrastructure. Its writing or sometimes postmortem makes good brain fertilizer. Not so much more. Beyond that I wouldn't rush to implement scalability du jour. A setup that works for a certain service won't necessarily work for another unless yours is a very close replica. Based on my experience in this area, and I'm a performance seeking nut, each platf…

Spot on! I bet there are hundreds of different stories like this with unconventional uber-hacks for performance.

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

#162

Post by calpaterson »

spotman wrote: post #93
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…

>> 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. InnoDB does implement MVCC. MVCC is not a silver bullet. >> Do not use transactions, which introduce locks. Instead, use applicative transactions. > Or just use a database that handle transactions more efficiently. Easy to say, hard to implement at this scale. If you do…

> Having something in a single table that is denormalized is always going to be faster than having an elegant data model with "Everything In It's Right Place"

This one folk wisdom that is untrue. There are significant speed disadvantages relating to large blobs of data the database doesn't understand. Serialisation time makes returning large JSON/XML objects expensive when you only need a small part. Overwriting a whole object to increment a counter is an unnecessary source of IO. Duplicating JSON keys in every record bloats the size of your working set, making it more difficult to fit into memory (or the fast part of your SAN).

99% of denormalisation out there is unnecessary and has inferior performance. The best route to performance with row store SQL databases (any database?) is two fold: 1) get an expert on your database to help you write your code and 2) get an expert on your hardware to help you choose wisely. Denormalisation is typically a way to take a performance problem and make it worse while introducing data corruption and race conditions.

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

#163

Post by Illniyar »

ysleepy wrote: post #156
Illniyar wrote: post #155

Two things that are sorely missing in this comparison to NoSql is: How are they performing horizontal scaling, I'm guessing they aren't, without addressing the issue of sharding and scaling they can't really compare the solution to NoSql - it is the number 1 feature that NoSql has over RDBMS. If they are achieving 1ms response time , then they almost certainly have the entire table in memory cache. What happens when…

1. They probably don't need sharding, since the dataset is small enough to just replicate it in mirrors. 2. 1ms is achievable with SSDs, but 200K q/minute seems slow my gut feeling tells me. This post is more like "ha we don't need NoSQL for this special use case" - Once you need scaling and some sort of atomics, you quickly have to use HBase for row-level atomicity and scaling. Redis is probably better suited for th…

Why HBase? why not just shard your keys?

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

#164

Post by StevePerkins »

narfz wrote: post #77
agentgt wrote: post #72

Earlier quoted context omitted.

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.

we did the same and then switched to the native UUID type. it eliminates the need for a unique index and we saw a drop in storage space by 1/2. it's totally worth converting UUID to the uuid field. ALTER TABLE my_table ALTER COLUMN my_uuid TYPE uuid USING uuid::uuid;

Same, but we use raw binary columns (i.e. "BINARY(16)" for MySQL and "BYTEA(16)" for PostgreSQL).

Conversion between the database-native UUID type and the application-layer UUID type is often so flaky (particularly with Java and JPA).

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

#165

Post by mdellabitta »

tagrun wrote: post #144
wtetzner wrote: post #140

Earlier quoted context omitted.

>Why do you think it's a UUID? Because of this: >Also notice that we are not using serial keys; instead, we are using varchar(50), which stores client-generated GUID values

GUID and UUID refer to different things in general. Also, depending on the context, they can be longer than 128-bits. Oracle Coherence API defines 256-bit UUIDs for example (which is clearly not RFC 4122 or Microsoft GUID, but it still is an identifying number which can statistically be called unique, which a UUID is). As long as it meets the statistical properties for collision, I don't see any problems with making…

Do you think it's more likely that they invented a unique id scheme that requires 50 bytes, or that they're using an overly wide datatype for ordinary UUIDs?

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

#166

Post by huehehue »

BinaryIdiot wrote: post #41
tqwhite wrote: post #37

Earlier quoted context omitted.

They are the same thing. Both should include time as well as the server address, etc.

Ah you're right. GUID is Microsoft's implementation of UUID. I guess, much like how many refer to tissues nowadays as Kleenex, the terms kinda got mixed around. At least in my experience from seeing how they're used.

Called a "proprietary eponym", for those curious.

https://en.wiktionary.org/wiki/proprietary_eponym

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

#167

Post by timruffles »

jondubois wrote: post #134

The problem with SQL DBs is that they just weren't designed for distributed computation to begin with. SQL doesn't take into account CAP theorem - So it lets you write queries which work on a single machine but which cannot scale to multiple machines. On the other hand, many NoSQL databases like MongoDB and RethinkDB have a query language which was designed to run on both single-machines and distributed infrastructur…

There's so much wrong with the above.

To pick a quick one: "query language which was designed to run on both single-machines and distributed infrastructure". Mongo has no fewer than THREE query syntaxes: standard, map-reduce[1], and the aggregate pipeline.

'homogeneous', lol.

[1] which even Mongo employees recommend people avoid like the plague https://www.linkedin.com/pulse/mongodb-frankenstein-monster-...

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

#168

Post by [deleted] »

jondubois wrote: post #134

The problem with SQL DBs is that they just weren't designed for distributed computation to begin with. SQL doesn't take into account CAP theorem - So it lets you write queries which work on a single machine but which cannot scale to multiple machines. On the other hand, many NoSQL databases like MongoDB and RethinkDB have a query language which was designed to run on both single-machines and distributed infrastructur…

[deleted]

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

#169

Post by morgo »

pmontra wrote: post #47
Thaxll wrote: post #29

Earlier quoted context omitted.

MySQL is faster than pg, you should ask why Facebook is running the largest MySQL shop.

Maybe because they started with a tiny LAMP system in 2004 and got stuck there to the point they invested considerable resources to write their own PHP interpreter and optimize MySQL. From https://www.percona.com/blog/2014/03/27/a-conversation-with-... "we had the MySQL engineering talent we needed to work with the Oracle team to get 5.6 ready for production at our scale." "We all worked hard to adapt 5.6 to our scal…

Harrison answered this question here: https://www.quora.com/Is-Facebook-considering-ditching-MySQL...

They continue to use MySQL on new projects.

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

#170

Post by gaius »

jondubois wrote: post #134

The problem with SQL DBs is that they just weren't designed for distributed computation to begin with. SQL doesn't take into account CAP theorem - So it lets you write queries which work on a single machine but which cannot scale to multiple machines. On the other hand, many NoSQL databases like MongoDB and RethinkDB have a query language which was designed to run on both single-machines and distributed infrastructur…

enforce a schema in the application code

HA HAHA HAHA

Post reply on HN