Scaling to 100M: MySQL Is a Better NoSQL

> When someone clicks a link to a Wix site... That server has to resolve the requested site from the site address by performing a key/value lookup URL to a site.

So Wix uses MySQL to resolve site routes internally? Is this the best way to do it? Would it be possible to use internal domain names and rely on DNS to resolve everything?

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

#7

Post by stplsd » Tue, May 24, 2016, 5:47 PM UTC

rantanplan wrote: post #2

And PostgreSQL is a better MySQL so... all is settled?

Is it? MySQL improved a lot since 5.1 days, you know.

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

#8

Post by wefarrell » Tue, May 24, 2016, 5:49 PM UTC

I was expecting a comparison but they only presented one side.

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

#9

Post by luka-birsa » Tue, May 24, 2016, 5:52 PM UTC

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.

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

#10

Post by xrstf » Tue, May 24, 2016, 5:52 PM UTC

I wonder if using the memcached plugin for InnoDB[1] would speed things up even more, at the expense of not having flexible queries (and thereby introducing multiple roundtrips) anymore. Presumably, they are using simple "SELECT * FROM table WHERE id = ?" in most places anyway, so that could be an okay tradeoff to make.

[1] https://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.htm...