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

61–70 of 183 posts

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

#61

Post by CraigJPerry »

jlas wrote: post #35
CraigJPerry wrote: post #34

Earlier quoted context omitted.

Define best but it's a pretty reasonable approach. Some DNS servers (powerdns is an example from memory) use mysql over more traditional back ends like dbm which aren't so hot for high volumes of zone changes. I imagine a site like wix could be pretty tough on DNS. Re: nosql, I'm coming at that with really positive experiences in Cassandra but I can't imagine what kind of DNS system it would be a good fit for. The ab…

It sounds reasonable, but with DNS you'd get geographic distribution for free, right? Won't you have to do something like sharding to achieve a similar thing with MySQL?

Hmmm I don't think you'd get geo dist for free. For example, I don't think start of authority can be shared by multiple resolving servers. Or if it can, it's a feature of some specific dns implementation.

You get free caching which is tolerant to partitions, but you'd get that with either solution since it's largely the forwarding dns servers which make that happen and the difference here is constrained to the authorative resolving dns servers.

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

#62

Post by peter_d_sherman »

Aside from the MySQL vs. Other DB debate (which I refuse to take part of, although I'm willing to ascribe good points to all camps), this article is absolutely excellent with respect to acting as a guide for people who want to use MySQL as a Key/Value store. Absolutely stellar article! All of the points are dead-on. I applaud the author for putting together so much specific information about tuning MySQL for Key/Value in one place, and the ridiculous speed and scalability you can get if you do it correctly. (That being said, NoSQL Key/Value databases are good too.)

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

#63

Post by gshulegaard »

luka-birsa wrote: post #9
tiffanyh wrote: post #3

Since Wix is using MySQL as a key-store ... I wonder why they didn't look at using Postgres HStore [1]. HStore is a key value store built directly in the RDBMS of Postgres. [1] http://www.postgresql.org/docs/9.6/static/hstore.html

We've drank the NoSQL coolaid mostly as we prefered a schemaless approach to our database and couchdb looked like a cool thing to use. Tested, deployed in production abd after a while we figured out that most of the promises about performance, stability, etc we're mostly bull. HStore was released, we've migrated to PG and we can't be happier. Zero issues so far.

Just curious, but why use HStore instead of JSONB?

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

#64

Post by wvenable »

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…

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.

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

#65

Post by hodgesrm »

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…

Facebook guys as I understand it did look carefully at PostgreSQL; at least some of the engineers are very familiar with its internals. They found MySQL satisfactory for a variety of reasons including ability to engineer better performance but also replication which was much better in MySQL for a long time. In fact, for an interesting perspective on the "Facebook stuck on MySQL" topic see [1].

Interestingly much Facebook database work has been outside the relational orbit on systems like Cassandra and HBase, as well as RocksDB. The choice for most web properties today is not MySQL vs. PostgreSQL but RDBMS vs. "other" systems.

[1] https://dom.as/2011/07/08/stonebraker-trapped/

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

#66

Post by calpaterson »

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…

This article is pretty terrible but just in point of fact: it looks like they are using MySQL's InnoDB backend - which does support transactions and MVCC. If they're even talking about avoiding transactions for speed purposes (no matter how stupidly) they must be talking about Inno because in MyISAM BEGIN and COMMIT are no-ops.

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

#69

Post by takeda »

wheaties wrote: post #20
matthewmacleod wrote: post #12

Earlier quoted context omitted.

That's true, and I don't doubt that many developers' opinion of MySQL is tainted by some of the issues in earlier versions. It's still difficult to see what newer versions offer over Postgres though - and Postgres has a lot of bonus features too (like the JSON storage types, which are sublime)

I'm a big believer in PostgreSQL but it does have one large and glaringly bad area which needs addressing: distribution. MySQL does Master-Master well. PostgreSQL has been a "chose your own adventure" for a long, long time. With the changes they're planning to make to allow better replication, that will change. Right now, MySQL has that aspect beat.

The thing is that generally in Postgres is conservative and avoids features that would endanger data, unless they have a good solution for it.

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

#70

Post by calpaterson »

gshulegaard wrote: post #63
luka-birsa wrote: post #9

Earlier quoted context omitted.

We've drank the NoSQL coolaid mostly as we prefered a schemaless approach to our database and couchdb looked like a cool thing to use. Tested, deployed in production abd after a while we figured out that most of the promises about performance, stability, etc we're mostly bull. HStore was released, we've migrated to PG and we can't be happier. Zero issues so far.

Just curious, but why use HStore instead of JSONB?

Presumably because HStore predates JSONB
Post reply on HN