Considerações sobre a migração da Uber do Postgres para o MySQL

Recentemente, fui questionado sobre o artigo da Uber que explicava os motivos da migração do Uber do Postgres para o MySQL.

Considero que as discussões causadas por esse tipo de artigo são muito saudáveis e que a mudança e a atualização de tecnologias são de grande importância na evolução das aplicações. Na época da publicação do artigo pela Uber, diversos argumentos bem embasados a favor e contra a migração foram publicados pelas comunidades do MySQL e do Postgres, e estes, certamente, contribuíram para a evolução das duas ferramentas.

Contudo, as motivações listadas no artigo devem ser observadas com atenção, já que geralmente são aplicáveis ao ambiente específico da empresa Uber. É imprescindível que escolhas tecnológicas estejam em sincronia com as necessidades de cada corporação. Considerando o ecossistema de tecnologias extremamente "heterogêneo" da IMA, a atualização e melhoria de ferramentas existentes, juntamente com a pesquisa de novas tecnologias, são de grande importância para a melhoria contínua dos negócios.

Voltando ao tema do artigo, é preciso ressaltar que a Uber não utiliza o MySQL como uma base de dados relacional tradicional, e sim como um backend para seu storage de dados estilo NoSQL, o Schemaless. Também é preciso notar que a versão do Postgres utilizada era a 9.2, uma versão relativamente antiga, que possuía um bug em seu mecanismo de replicação.

O artigo menciona que a base de dados sofria uma carga extremamente alta de Updates e que suas tabelas continham um número grande de índices. Esse tipo de ambiente pode causar problemas de escala na arquitetura atual do Postgres, onde a atualização de uma linha pode desencadear diversas alterações em todos os índices da tabela. No MySQL, a atualização de um valor indexado necessita de um número menor de escritas em disco.

As imagens a seguir, retiradas do próprio artigo, mostram uma representação da diferença entre as duas arquiteturas:

No MySQL:

Figura 1

Fonte: UBER (2016)

No caso do MySQL, os índices secundários "apontam" para a chave primária da tabela. Uma vantagem é que modificações em dados da tabela necessitam apenas de uma alteração na chave primária, e não afetam os demais índices.

No Postgres:

Figura 2

Fonte: UBER (2016)

No caso do Postgres, todos os índices apontam diretamente para o campo em disco que representa uma linha da tabela. Alterações em dados da tabela desencadeiam alterações nas estruturas de todos seus índices vinculados.

O método de indexação utilizado pelo Postgres apresenta desvantagens em relação ao MySQL em tabelas muito indexadas e que sofrem uma quantidade extrema de alterações simultâneas. Porém, essa arquitetura favorece consultas que utilizam buscas em índice, já que não é necessária uma leitura a mais na chave primária da tabela para o retorno dos dados.

Outro ponto mencionado no artigo é o método de replicação nativo do Postgres 9.2, baseado na distribuição de escritas em baixo nível em disco (WAL shipping). O fato de serem atingidos pelo bug na replicação que afetava certas subversões do Postgres 9.2 e a existência de limitações na distribuição de sua rede levou os engenheiros da Uber a escolherem a replicação lógica do MySQL como uma melhor opção. Ambos os métodos de replicação apresentam vantagens e desvantagens e a versão mais recente do Postgres, a versão 10, também passa a oferecer o modo de replicação lógica nativamente.

Na verdade, o título "Porque trocamos o Postgres pelo MySQL" pode ser considerado uma simplificação. Algo mais próximo da situação descrita seria "Porque trocamos a versão 9.2 do Postgres pela nossa base de dados personalizada construída sobre o MySQL". Curiosamente, a própria empresa já havia realizado uma migração do MySQL ao Postgres no ano de 2013. Portanto, não seria surpresa uma volta ao Postgres ou a migração para outras opções de bancos de dados pela Uber, uma vez que tecnologias de banco se encontram em evolução constante.

Referências Bibliográficas:

UBER Engineering, Why Uber Engineering Switched from Postgres to MySQL. Disponível em:
<https://eng.uber.com/mysql-migration/>. Acesso em 19 de Outubro de 2017.

GitHubGist, Compilation of the Uber Facts on PostgreSQL to MySQL Migration. Disponível em <https://gist.github.com/sebastianwebber/5b67fb2866dbc300dab225ded5f28618>. Acesso em 19 de Outubro de 2017.

Use the Index, Luke, On Uber's Choice of Databases. Disponível em <http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases>. Acesso em 19 de Outubro de 2017.