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

31–40 of 183 posts

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

#31

Post by BinaryIdiot »

> Use client-generated unique keys. We use GUIDs.

Minor note but wouldn't UUIDs be better since they're time based? Sure it's really unlikely to hit an already used GUID but an UUID makes it impossible.

In fact is there a use case where it's better to use GUIDs over UUIDs? I couldn't think of one but I could be omitting something from my thinking so I'm curious.

Edit: apparently GUID and UUID are the same thing and GUID is simply Microsoft's original implementation of UUID. All this time I had no idea...

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

#32

Post by TylerE »

stplsd wrote: post #7
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.

Latest postgres's have improved tons too. Seems like we're seeing 10% speedups with every point release. Some of the new parrellization stuff in 9.6 is really sexy.

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

#33

Post by TylerE »

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…

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

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

#34

Post by CraigJPerry »

jlas wrote: post #6

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

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 ability to tune CAP to fit DNS may be useful but in general I think of Cassandra as the solution you think about when your 2 node vertically scaled monster can't keep up.

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

#35

Post by jlas »

CraigJPerry wrote: post #34
jlas wrote: post #6

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

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?

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

#36

Post by jjoe »

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 platform, and even each traffic pattern, needs its own thinking hat.

That's what makes it so fun!

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

#37

Post by tqwhite »

BinaryIdiot wrote: post #31

> Use client-generated unique keys. We use GUIDs. Minor note but wouldn't UUIDs be better since they're time based? Sure it's really unlikely to hit an already used GUID but an UUID makes it impossible. In fact is there a use case where it's better to use GUIDs over UUIDs? I couldn't think of one but I could be omitting something from my thinking so I'm curious. Edit: apparently GUID and UUID are the same thing and G…

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

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

#38

Post by backslash_16 »

jlas wrote: post #6

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

I'm pretty new to this and just learned some more about routing requests in a cloud service at scale. For a lot of services where the location of the resources might change (frequently sometimes), you want to handle the routing internally and not use DNS because of the lag times and complexity of TTL and caching.

For companies other than Wix I don't know what is used to handle it on the back end but I imagine it's either some specialized piece of hardware than can handle an insane load or some commodity hardware / cloud service & in-house software like here.

At the end of the day, and I'm sure I'm missing some edge cases, I think it's basically a service that provides a mapping of domain.com/user-resource-or-website to the location of their resources with no lag time when changes are made.

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

#39

Post by agentgt »

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

IRC If you are using JDBC (which is pretty much the only choice on Java) HStore is a pain to use since its query operators conflict with JDBC's parameter syntax ("?").

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

#40

Post by tracker1 »

TheGuyWhoCodes wrote: post #30
whalesalad wrote: post #18

Earlier quoted context omitted.

Reddit does something very similar. https://kev.inburke.com/kevin/reddits-database-has-two-table... I think the important thing to note here is that there are lots of different ways to use any given tool that can fit your use case without being an atrocity.

And they did it because of maintenance problems not (just) performance (from the link you provided). But they also said "Postgres was picked over Cassandra for the key-value store because Cassandra didn’t exist at the time. Plus Postgres is very fast and now natively supports KV." Which isn't patronizing like the article OP linked. http://highscalability.com/blog/2013/8/26/reddit-lessons-lea...

Thanks for that... I think it depends on one's needs... it would surprise me if Wix as using MySQL without sharding data either by route and/or site.

Personally, I'd be inclined to use PostgreSQL for most things once they have an in the box solution for replication and failover that doesn't require a commercial contract for a sane solution. Every time I've used mySQL (admittedly not for about a decade), I wind up with a lot of WTF moments. If I'm paying for it, may go with MS-SQL, or a hosted "cloud" provider as tbh, no interest in being a DBA.

I really like RethinkDB's approach as a no-sql solution, and their admin interface is second to none in this space. If you really need more scale (more than around 20 servers or so), then you should probably be using Cassandra, and/or supplementing with the likes of ElasticSearch.

In any case, if you want real-time data for hundreds of millions of users, you're going to have data partitioning and redundant replication and caching solutions.

I worked at GoDaddy on Website builder while they were transitioning their publishing target to C*, and have to say it performs incredibly well as basically a distributed file system in the role described in the post article.

Post reply on HN