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

21–30 of 183 posts

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

#21

Post by grossvogel »

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?

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

#22

Post by stplsd »

xrstf wrote: post #10

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

I wonder about this myself, anyone has experience using this? MySQL 5.6 brought many long awaited features, like schema update without locking tables https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.ht... (bye bye Percona tools).

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

#23

Post by golergka »

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?

On a site constructor with custom URLs created by millions of users for their websites every day?

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

#26

Post by danudey »

matthewmacleod wrote: post #12
stplsd wrote: post #7

Earlier quoted context omitted.

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

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 things, which makes the most common (and most of the uncommon) problems eminently google-able.

Anecdotally, I've avoided Postgres also in part because it had the same problem that Perl had when I got into Linux: the community was pretty toxic and unwelcoming. I asked about replication once, and I got a bunch of answers that fell into a few categories: 'Why on earth do you need replication?', 'You don't need replication, Postgres is fast enough', 'set up a script to rsync your data directories over and over again', 'mysql replication is unreliable so you shouldn't use it so it doesn't matter'.

That sort of attitude drove me (and, I'd wager, a lot of other people) away from Postgres and towards the vastly more welcoming MySQL community, and I'd wager that a lot of people just kind of stuck there because why switch?

Postgres has added a lot of pretty great features lately, and it seems good? But I'm left wondering why I should use Postgres for my RDBMS, my JSON data store, and my KV store, when history has shown that one piece of software that expands to do everything rarely does any of it well.

(Postgres has since gained replication abilities)

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

#27

Post by tremon »

dyeje wrote: post #11
bchociej wrote: post #4

Kinda begging the question aren't we? I turn to nosql for things that aren't key-value, generally.

What do you mean? Isn't NoSQL inherently key-value?

All structured data can be represented as key-value, that includes SQL. They just differ in what constraints are used for the keys and values.

As for your question, NoSQL datastores can be grouped into multiple categories:

- column stores (like hadoop, cassandra, informix), which optimize for sharded and distributed storage of related data elements

- document stores (like elasticsearch), which focus on metadata organization for large opaque (binary) objects

- key-value stores (like redis, openldap), which are basically unstructured, associative arrays (hash maps). They allow the most storage freedom, and are hardest to optimize.

- graph databases (like neo4j, trinity), where more information is carried in annotated inter-object links than in the objects themselves.

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

#28

Post by BinaryIdiot »

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.

> Tested, deployed in production abd after a while we figured out that most of the promises about performance, stability, etc we're mostly bull.

Well, to be fair you would typically expect a database that's the equivalent of a remote hash table to be pretty much as fast as you can get. Now I don't have any experience with couch but most of the other key value stores I've used they scream with performance. But if you're doing anything beyond basic manipulations then it's going to require a lot of tuning depending on the solution you went with.

But RDMS can be very similar. Both are useful tools when used correctly and there is a huge amount of overlap in terms of capability.

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

#30

Post by TheGuyWhoCodes »

whalesalad wrote: post #18
TheGuyWhoCodes wrote: post #13

This is basically "We made it work, easy, all the rest are wrong". Wix is 10 years old, they probably started with MySql and stuck with it, is it wrong? Maybe, maybe not. If they were to start today would they have used Mysql aswell or gone with another solution? Did they spend the last 10 years building tools to help them scale MySql (at which point it's easy for them to operate) rather than use a tool that had mult…

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

Post reply on HN