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

51–60 of 183 posts

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

#51

Post by jarnix »

grossvogel wrote: post #16
okigan wrote: post #5

>An active-active-active setup across three data centers. Any info how "active-active-active" (I assume 3 aws regions) is accomplished?

Some kind of master-master replication, probably: https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-replic...

In my company we are using a mysql cluster based on galera, (percona xtradb server) and it's a master-master solution that is rather easy to deploy and maintain. The only limit was that we had to use a single server for writes (that would make the "cluster" thing kind of useless but it's not in fact, we are using a load balancer on top of the cluster and the load balancer decides of the "master" where writes go so it's transparent to our application), definitely worth a try.

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

#52

Post by fapjacks »

grossvogel wrote: post #21
fapjacks wrote: post #15

This may be an unpopular perspective, but here goes. For many years I ran a business doing web development. I had many clients approach me who were using Wix, and who I could not help, because Wix had effectively taken hostage their images. Because of those years of bad experiences (telling clients that they are screwed unless they keep paying Wix), I do not trust Wix, and so I do not trust this post. Should those cl…

By "taken hostage their images," do you mean that literal graphic files uploaded to Wix servers were somehow made inaccessible to the user?

Yes, exactly. I don't know how they do it now, but Wix did the "one big Flash blob as a website" and did not make data available to clients to download once they had been uploaded. So images and other data that had been "compiled" into the Flash blob were erased or something. There was no warning about this, and it took many by surprise. This effectively forced people to renew their subscription to Wix who otherwise wanted to use something else. The worst was a friend of a friend whose elderly mother had used Wix to upload old family photos thinking that Wix was a safe place to store them, not knowing any better. I felt so bad for that woman. I have no love for Wix at all.

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

#55

Post by return0 »

This seems specific to their use case. He shows an example with a subquery. I wonder why they don't break that to two queries. The should be fast enough if cached, and would prevent the need for both tables to be unlocked during query.

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

#56

Post by koolba »

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 store them would be the binary bytes (which is how postgres stores them). If it's hex without dashes, it'll be varchar(32). If it's hex with dashes, it'll be varchar(36). Why did they pick 50? Future growth? Smart keys? Schema designer doesn't know what a UUID actually is?

> Do not normalize.

Bullshit. Normalize as much as is practical and denormalize as necessary. It's much easier to denormalize and it greatly simplifies any transaction logic to deal with a normalized model.

> Fields only exist to be indexed. If a field is not needed for an index, store it in one blob/text field (such as JSON or XML).

This is terrible advice. Fields (in a table) exist to be read, filtered, and returned. If everything is in a BLOB then you have to deserialize that BLOB to do any of those. That doesn't mean you can't have JSON "meta" fields but if your entire schema id (id uuid, data json) you're probably doing it wrong. It's next to impossible to enforce proper data constraints and all your application logic becomes if/then/else/if/then/else... to deal with the N+1 possibilities of data. Oh and when you finally add a new one, you have to update the code in M+1 places.

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

#58

Post by ngrilly »

danudey wrote: post #26
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)

Based on my experience: MySQL is significantly easier to set up, and it's much easier to admin. PG still seems to do the thing where it assumes your system user is your database user unless you do a bunch of things, and the weird blurred lines between the operating system and the database can get really confusing at the start. On top of that, MySQL is well-documented and lots of people use it for lots of different th…

> On top of that, MySQL is well-documented

I seriously disagree with that. Documentation is one of MySQL's weakness, especially compared to PostgreSQL which is known to have one of the best documentation in the open source world.

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

#60

Post by suneilp »

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.

Couchdb isn't exactly the best thing to judge NoSQL by today especially by it's old performance issues, lack of automatic compaction, indexing on demand instead of proactive background indexing, etc.
Post reply on HN