Live data from Hacker News

Scaling to 100M: MySQL Is a Better NoSQL

blog.wix.engineering

81–90 of 183 posts

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

#81

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…

> If they were to start today would they have used Mysql

Uber built something similar in the last couple of years.

https://eng.uber.com/schemaless-part-one/

So did Dropbox.

https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pock...

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

#83
post #80

I have not heard about "Wix" before, but maybe they should have done some more research before picking this name. To a German this sounds like "wichsen" which means, well, "wank"[1]. [1] http://dict.leo.org/ende/index_de.html#/search=wichsen

Not only is this completely off-topic, they are a publicly traded company NASDAQ: WIX and they are currently valued at ~$1B.

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

#84
"Many developers look at NoSQL engines—such as MongoDB, Cassandra, Redis, or Hadoop" Noone uses Hadoop as a database. On the other hand, HBase which uses HDFS as underlying storage is a great NoSQL database that we use in production.

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

#85
post #77
post #72

Earlier quoted context omitted.

We use varchar for UUID (on postgres) which surprisingly hasn't been that terribly performance wise. And yes we do use varchar(36) although on postgres it doesn't really matter because I think almost all varchars are text. I would love to switch to native UUID someday though.

we did the same and then switched to the native UUID type. it eliminates the need for a unique index and we saw a drop in storage space by 1/2. it's totally worth converting UUID to the uuid field. ALTER TABLE my_table ALTER COLUMN my_uuid TYPE uuid USING uuid::uuid;

And you want as much of the index as possible in RAM. When the index is 10 times larger than necessary and do not fit in your RAM, you get a very expensive performance penalty!

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

#86

A little bit off topic, but I would like to hear more about using Solr [1] instead of any "real" NoSQL databases. I don't have experience with MongoDb and such, but I've always asked myself why someone wouldn't use Solr as a distributed NoSQL database... Am I wrong or, with Solr, you get that key/value scalable storage AND you get advanced search features as an extra? Why would I want to use MongoDb instead of Solr?…

Haven't worked with solr but with elastic-search which are both based on lucene.

Some issues are:

async indexes, unable to modify/remove indexes, unable to grow/shrink number of shards etc (basically search why not use es as primary data store)

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

#87
post #80

I have not heard about "Wix" before, but maybe they should have done some more research before picking this name. To a German this sounds like "wichsen" which means, well, "wank"[1]. [1] http://dict.leo.org/ende/index_de.html#/search=wichsen

Not only is this completely off-topic, they are a publicly traded company NASDAQ: WIX and they are currently valued at ~$1B.

Then please forgive my ignorance. I was not aware that they are so big. Even more though I'm surprised about their name. Reading it really feels weird to me.

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

#88
post #37

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

note there are like 5 versions of UUID, and only v1 and v2 include time and server address. It's also considered bad practice to use them, as it makes your UUID's guessable.

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

#89
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

Presumably they preferred to stay within the mysql world. I didn't read the article in detail, but I couldn't help but wonder why not use innodb more directly [1]? Imagine how much CPU is wasted using a full blown RDBMS SQL engine on top of InnoDB just to do key-value read/writes.

I have some experience with this having worked on an experimental storage engine for mysql that we connected to a transactional in-memory k-v store. The performance penalty for simple k-v workload through mysql was quite substantial, though our storage engine code was probably not sufficiently optimized. It would be interesting to explore this for innodb though

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

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

#90
post #80

I have not heard about "Wix" before, but maybe they should have done some more research before picking this name. To a German this sounds like "wichsen" which means, well, "wank"[1]. [1] http://dict.leo.org/ende/index_de.html#/search=wichsen

As a neighbor (Dutch) I can totally understand it and I still laugh pretty much every time I hear flickr[1]. Still, if I finally found a cool name for my project after a long search (it often is), I'm not going to cancel it just because it "sounds like" penis in Arabic or something.

http://www.woorden.org/woord/flikker (tl;dr: homosexual)

Post reply on HN