News for hackers. Stuff that matters.
Re:Why Uber Engineering Switched from Postgres to MySQL by busterarm on Tuesday July 26, 2016 @01:44PM (#12167392)
Can't agree with this post enough.

I find their whole writeup to be terribly myopic. When they started their service, Postgres was almost certainly the right choice for what they were building and their MySQL setup was not. Now Postgres is less effective for them.

These kind of tech switches are _inevitable_ if you're making the right choices for your organization.

This strikes me as very similar to the article where Twitter ditched Rails. The focus should be inward... how they chose a tool that didn't support their use case and how they solved the problem, but instead they're about the flaws (that aren't really flaws) of the tool.

It's always the craftsman.

Re:Why Uber Engineering Switched from Postgres to MySQL by stubish on Wednesday July 27, 2016 @05:29AM (#12171514)
While the article is discussing PostgreSQL vs MySQL, Uber's actual win seems to be from switching their data model to their sharded Schemaless key=value store. I expect they would have got this win no matter what backend they chose for Schemaless.
Re:Why Uber Engineering Switched from Postgres to MySQL by _Codemonkeyism on Tuesday July 26, 2016 @02:24PM (#12167716)
"1B+ rows in it with mysql?"

Been there, really no fun.

Re:Why Uber Engineering Switched from Postgres to MySQL by midom on Tuesday July 26, 2016 @02:37PM (#12167827)
As long as you can shard (across multiple instances, or even within same instance, to avoid B-Tree latching), 1B+ rows within MySQL is piece of cake.

Also, MySQL* is getting LSM-Tree support lately, which makes high performance data ingestion combined with OLTP workload quite feasible.

* https://github.com/facebook/mysql-5.6/tree/webscalesql-5.6.2...

Re:Why Uber Engineering Switched from Postgres to MySQL by _Codemonkeyism on Tuesday July 26, 2016 @11:17PM (#12170271)
"I wonder how Uber adds an index to a table that already has 1B+ rows in it with mysql?"

"As long as you can shard "

Not sure how sharding helps with 1B+ tables when adding indices, care to share?

Re:Why Uber Engineering Switched from Postgres to MySQL by Swannie on Wednesday July 27, 2016 @08:06PM (#12177465)
This is: "Split the index in your application code."

And then do your joins, in your application code.

Re:Why Uber Engineering Switched from Postgres to MySQL by fasteo on Tuesday July 26, 2016 @03:02PM (#12168016)
Percona to the rescue [1]. Works flawlessly, at least in our case.

[1] https://www.percona.com/doc/percona-toolkit/2.1/pt-online-sc...

Re:Why Uber Engineering Switched from Postgres to MySQL by barrkel on Tuesday July 26, 2016 @05:49PM (#12168974)
Am there right now, it's not really a problem - you just have to plan your schema changes and use Percona OST.
Re:Why Uber Engineering Switched from Postgres to MySQL by maximegarcia on Tuesday July 26, 2016 @04:27PM (#12168522)
https://github.com/soundcloud/lhm

Saved my life a few time :)

Re:Why Uber Engineering Switched from Postgres to MySQL by _Codemonkeyism on Tuesday July 26, 2016 @11:19PM (#12170284)
Thanks!
Re:Why Uber Engineering Switched from Postgres to MySQL by Groxx on Saturday August 06, 2016 @07:45PM (#12240407)
Also been there. Percona Toolkit works fine (though it's not load-aware enough, so we changed the backfill logic).

Plus, in 5.7, there are a fair number of online-DDL changes, and adding indexes is (usually) one of them.