Re: Uber migrated from Postgres to MySQL

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: Uber migrated from Postgres to MySQL
Дата
Msg-id CAKt_Zfts-k7X6b4y22s1zdgW8z4vUu_u_+XpLgqa16HzWHa_uQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Uber migrated from Postgres to MySQL  (Edson Richter <edsonrichter@hotmail.com>)
Список pgsql-general


On Thu, Jul 28, 2016 at 8:09 PM, Edson Richter <edsonrichter@hotmail.com> wrote:
Em 28/07/2016 13:07, Chris Travers escreveu:


On Thu, Jul 28, 2016 at 3:38 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Wed, Jul 27, 2016 at 9:51 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> On 27 July 2016 at 15:22, Scott Mead <scottm@openscg.com> wrote:
>>
>>  "The bug we ran into only affected certain releases of Postgres 9.2 and
>> has been fixed for a long time now. However, we still find it worrisome that
>> this class of bug can happen at all. A new version of Postgres could be
>> released at any time that has a bug of this nature, and because of the way
>> replication works, this issue has the potential to spread into all of the
>> databases in a replication hierarchy."
>>
>>
>> ISTM that they needed a tire swing and were using a dump truck.  Hopefully
>> they vectored somewhere in the middle and got themselves a nice sandbox.
>
>
> At least his bug got fixed. The last 2 bugs I reported to MySQL resulted in
> an initial refusal to accept any problem existed, followed by (once that
> particular strategy had run out of steam) the developer simply ignoring the
> bug until it was closed automatically by their bug system. As far as I'm
> aware those bugs still exist in the most recent version.

Best / worst MySQL bug was one introduced and fixed twice. Someone put
in a short cut that sped up order by by quite a bit. It also meant
that order by desc would actually get order by asc output. It was
inserted into the code due to poor oversite / code review practices,
then fixed about 9 months later, then introduced again, and again,
took about a year to fix.

The fact that it was introduced into a General Release mid stream with
no testing or real reviews speaks volumes about MySQL and its
developers. The fact that it took months to years to fix each time
does as well.


As for MySQL issues, personally I love the fact that a single query inserting a bunch of rows can sometimes deadlock against itself.  And I love the fact that this is obliquely documented as expected behavior.  May I mention I am *really glad* PostgreSQL doesn't go the whole multi-threaded backend route and that this is exhibit A as to why (I am sure it is a thread race issue between index and table updates)?  

Sorry, I think this is a biased vision. Multi-threading will show as much problems as multi-process - both has to have simultaneous access (or, at least, right semaphor implementation to serialize writes and syncronize reads).
The fact is **on this point at least** is that Postgres is correctly implemented, and MySQL is faulty.
I've faced the "lost FK integrity hell" (caused by the problem above) with MySQL long before decided to migrate all systems to PostgreSQL.

Both have potential for the same sorts of problems to be sure, but the difference is that process isolation does give you some protection and helps contain the issues.  Not the only way to do so, to be sure.  But getting some extra help from the OS and CPU in this area really is not a bad thing.  My point is that I like the design decision here regarding PostgreSQL.
 
My personal experience is that MySQL is excellent for data that is not sensitive (web site, e-mail settings, etc). Everything else goes to PostgreSQL (or Oracle, or MS SQL Server, or Sybase, or DB2 - in *my* order of preference).

MySQL is a good system for a few sorts of problems.  InnoDB is well-optimized for simple primary key lookups.  So if really what you want is a SQL access to a dumb information store with network access and reasonable write scalability, it is not a bad system.  You will note that is actually pretty close to Uber's use case with schemaless.  But at that point, foreign keys are pretty close to being optional.....
 


Regards,

Edson Richter




--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.

В списке pgsql-general по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Uber migrated from Postgres to MySQL
Следующее
От: Vitaly Burovoy
Дата:
Сообщение: Re: Using timestamp(tz) in C functions