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

41–50 of 183 posts

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

#41

Post by BinaryIdiot »

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

Ah you're right. GUID is Microsoft's implementation of UUID. I guess, much like how many refer to tissues nowadays as Kleenex, the terms kinda got mixed around. At least in my experience from seeing how they're used.

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

#42

Post by rco8786 »

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…

GUID == UUID

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

#43

Post by tracker1 »

BinaryIdiot wrote: post #28
luka-birsa wrote: post #9

Earlier quoted context omitted.

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'…

It really depends on your use case... if you can rely on heavy caching, then working against a transactional sql database can work for the bulk of your application, while also "publishing" to a distributed k/v store...

Most applications are probably fine regardless of the underlying data store, and are better served by what works best for the model of the data, which can often be SQL. I'm more inclined to react for mongo or rethinkdb first, as I tend to think more in terms of more complex records/objects in most of the applications I've worked on.

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

#46

Post by ph33t »

I hate these stupid "my db is better than whatever db" articles. 1) What db to be used depends on the situation AND MORE IMPORTANTLY 2) what experience your staff has

I can say that 10 years go, I would have chosen M$SQL over MySQL and it would have been the correct choice. At the time I had almost 10 years experience with M$SQL and almost none with MySQL. Now I have more than 10 years of MySQL under my belt. AND the MySQL experience is more current. Right now I could choose between the two based on specific features and performance characteristics. For me to pick Posgresql because of a specific feature would be insane because I don't experience with it. No knock on Posgresql ... maybe I'll spend time with it and pick it for some down-the-road project.

I have implemented couchdb as a caching solution. I know how to manage, backup, and restore the database server. I have managed a 5 node cluster. If you ask me to implement NoSQL, it would be my choice for 2 reasons: 1. It can do the job. 2. I have experience making it do the job.

I'm sure there are 10 million people out there would would choose mongo in the same situation. The would not be wrong and they may come up with a superior solution. For me to implement Mongo today would be wrong - I would almost certainly come up with an inferior solution. for them, it would be stupid not to.

I'm not saying "don't learn anything new". I'm saying "don't gamble your business on technology with which you're not familiar".

Its a bit like backups ... the most important thing about a backup is not the technology you use, but whether you are capable of restoring and maintaining the backups.

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

#47

Post by pmontra »

Thaxll wrote: post #29
rantanplan wrote: post #2

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

MySQL is faster than pg, you should ask why Facebook is running the largest MySQL shop.

Maybe because they started with a tiny LAMP system in 2004 and got stuck there to the point they invested considerable resources to write their own PHP interpreter and optimize MySQL.

From https://www.percona.com/blog/2014/03/27/a-conversation-with-...

"we had the MySQL engineering talent we needed to work with the Oracle team to get 5.6 ready for production at our scale."

"We all worked hard to adapt 5.6 to our scale and ensure that it would be production-ready. We found some issues after production deployment, but in many cases we could fix the problem and deployed new MySQL binary within one or two days"

"Performance regression of the CPU intensive replication was a main blocker for some of our applications" followed by a description of how they addressed that.

So it's not vanilla MySQL vs vanilla PostgreSQL. They tailored MySQL to their needs and keep honing it. What they do has little resemblance with what the other 99.9999% of companies do, and I'm probably missing a few 9s. Another excerpt from that post highlights the differences:

"For example, typical MySQL DBA at small companies may not encounter master instance failure during employment, because recent mysqld and H/W are stable enough. At Facebook, master failure is a norm and something the system can accommodate."

My take: if they started with and stuck to PostgreSQL they'd have to work on it as they did on MySQL.

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

#49

Post by eulor »

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)

If you knew what newer versions of MySQL offered, you would be aware that it also supports JSON.

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

#50

Post by Buttons840 »

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.

Has MySQL added support for Common Table Expressions (CTE) yet? CTE was added to the SQL standard in 1999.

I ask because I always miss this feature when querying MySQL.

Post reply on HN