tiagopassos.com

O Uber, como você deve saber, é uma empresa que trouxe para o mercado uma forma rápida, eficiente, e consideravelmente mais barata que os taxis conencionais para se locomover em várias cidades do planeta.

O que talvez não saiba é sobre a tecnologia por trás do serviço.

Aqui vou falar um pouquinho sobre a migração de bancos de dados realizada pelo Uber recentemente. O artigo original foi publicado em um blog do próprio Uber 20 dias antes de eu escrever esse post.

Minha intenção aqui não é traduzir nem fazer um comentário extenso sobre o texto, mas apenas pontuar as informações que achei mais interessantes. Vamos lá:

O Postgres tem um funcionamento que faz gerar várias linhas (fisicamente, no disco, chamada ctid) para uma mesma linha no banco de dados, ou seja, se você tem uma tabela que armazena os dados de uma pessoa, e você altera o telefone dela, uma nova linha física (ctid) é gerada.

Para a maioria dos sistemas, isso não chega a ser um problema. O Postgres tem um recurso chamado auto-vacuum que faz a limpeza das linhas antigas. A questão é que, de tempos em tempos, pode ser necessário parar o sistema por algumas horas e executar um vacuum full (limpeza geral), e para sistemas que não podem parar, isso pode ser um problema. Se muito tempo passa sem a execução de um vacuum full, o sistema começa a ficar lento.

Mas a grande questão para o Uber é que eles replicam os dados em diferentes data centers (costa leste e costa oeste dos Estados Unidos) para Recuperação de Desastres e, nesse caso, a replicação dessas linhas torna-se muito lenta e cara. Com frequência uma alteração estava sendo realizada e não sendo sincronizada corretamente.

O problema é agravado pelo fato de que no caso deles, muitas tabelas tinham muitos índices, e updates pequenos e frequentes eram executados.

Repare que é uma situação específica: replicação de dados em data centers diferentes, com updates frequentes e muitos índices.

Nem todo serviço funciona dessa forma, e obviamente, isso não quer dizer que o Postgres é um banco de dados ruim. Mas no caso específico do Uber, eles tiveram problemas.

Segundo o artigo, o MySQL (com engine InnoDB) cria uma camada a mais de abstração, o que normalmente é uma desvantagem pois deixa o sistema todo mais lento, mas é uma solução no caso da replicação, pois o MySQL replica o DML (update, insert, delete) propriamente dito, e não o registro físico da informação.

Outra questão é a atualização de versão. Usando a versão 9.2, eles tiveram problemas para atualizar para a 9.3, porque demorava tempo demais e o serviço não poderia ficar parado durante esse tempo. Para agravar a situação, todas as réplicas têm que usar a mesma versão, ou seja, eles não poderiam fazer a atualização primeiro em uma ráplica e depois no master, por exemplo. Acrescentam que isso foi resolvido na versão 9.4 em diante, usando o recurso pglogical, que adicona uma camada lógica para replicação.

No MySQL esse problema não existe. É possível, na maioria das situações operar com versões diferentes (já que o que é replicado é o DML em si).

Outro grande problema do Postgres é relativo ao número de conexões. Mesmo em sistemas com abundância de recursos, é bem difícil abrir mais que algumas centenas de conexões, porque o número de conexões é diretamente ligado ao número de processos (mais conexões, mais processos). No MySQL, o número de conexões é diretamente ligado ao número de threads.

Isso faz com que no MySQL seja possível abrir 10 mil conexões sem grandes problemas.

Veja o artigo original para obter mais informações:

• https://eng.uber.com/mysql-migration/

Outro artigo comentando o artigo do Uber:

• http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases (no fim desse artigo você pode enconrar links adicionais para obter mais informações)

Para instalar o PostgreSQL no Linux Mint ou Ubuntu, primeiramente você precisa criar um arquivo "source" para ser utilizado com o apt-get.

Abra o Terminal (CTRL + ALT + T) e digite:

sudo touch /etc/apt/sources.list.d/pgdg.list

Depois edite o arquivo com o editor de sua preferência. Usarei o pluma (Linux Mint). No Ubuntu você pode usar o gedit.

sudo pluma /etc/apt/sources.list.d/pgdg.list

A configuração abaixo serve para o Linux Mint 17 ou Ubuntu 14.04 (Trusty). Caso esteja utilizando outra versão, será necessário utilizar o repositório adequado. Dentro do arquivo, coloque o seguinte conteúdo:

deb http://apt.postgresql.org/pub/repos/apt/ trusty-pgdg main

Salve o arquivo e digite as seguintes linhas (uma por uma):

sudo apt-get install wget ca-certificates -y
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update -y
sudo apt-get upgrade -y
sudo apt-get install postgresql-9.4 pgadmin3 -y

Note que a linha "sudo apt-get upgrade -y" pode demorar bastante. O parâmetro -y serve para que não sejam feitas perguntas (sim para tudo).

Pronto! O PostgreSQL está instalado. Para este artigo foi utilizado o PostgreSQL 9.4 e o Linux Mint 17.

Agora você vai precisar definir uma senha para o PostgreSQL e em seguida pode começar a utilizá-lo!

Fonte: http://www.codeproject.com/Articles/898303/Installing-and-Configuring-PostgreSQL-on-Linux-Min

Aspas simples são utilizadas na estrutura de um comando SQL, sendo assim, podemos ter problemas se precisarmos exibir as aspas simples como um valor fixo. No meu caso, tinha que exibir latitude e longitude (que estava armazenado no banco em campos inteiros) e depois colocar as aspas simples e duplas fixas, ao lado do valor.

Sem mais lenga lenga, pra fazer isso você poder utilizar a função CHR, que retorna um caracter da tabela ASCII.

select
cast(chr(39) as varchar) as aspas_simples,
cast(chr(34) as varchar) as aspas_duplas

É possível que funcione da mesma forma em outros bancos.

Essa pergunta é feita por muita gente que trabalha com desenvolvimento e conhece alguma coisa de algum dos dois. No senso comum, se ouve muito o seguinte: “MySQL é pra coisas menores, mais simples. PostgreSQL é pra projetos de grande porte”. Mas será que isso é verdade? E porque escolher um ou outro?

O que eles têm em comum

• São Software Livre;
• São gratuitos (nem todo Software Livre é gratuito);
• São encontrados facilmente em vários provedores por aí;
• Possuem também suporte pago (do MySQL é oferecido pela Oracle. O do PostgreSQL é oferecido por empresas como EnterpriseDB);
• São bem populares, e por isso se encontra bastante documentação (mas se encontra mais material do MySQL).

O lado político da coisa

Do ponto de vista “político”, tem uma diferença importante entre eles: o MySQL é da Oracle, uma grande empresa multinacional. O PostgreSQL não. Ele é mantido diretamente pela comunidade.

Isso quer dizer que a Oracle é “dona” do MySQL e pode fechar o código a qualquer momento? Não, não é bem assim. Ela é dona da marca MySQL, e pode descontinuar o produto a seu bel prazer ou deixar de liberar a versão grátis. Mas todo o código já produzido é livre, e se alguém ou alguma empresa quizer dar continuidade ao projeto com outro nome (fazer um fork), pode fazer. Inclusive isso já aconteceu: foi lançado o MariaDB.

O MariaDB é baseado no MySQL e foca na compatibilidade com ele, então a ideia é que ele não vá se tornando cada vez mais incompatível conforme as versões vão sendo lançadas, e sim que ele permaneça lado a lado com o MySQL, mas sem ser da Oracle. O criador do MariaDB é um dos criadores do MySQL: o finlandês Michael “Monty” Widenius.

O problema é que a instabilidade das decisões de uma empresa como a Oracle pode afetar a confiança no produto. Foi o que aconteceu com o OpenOffice (também da Oracle). A comunidade estava instisfeita com o rumo que o projeto vinha tomando, e decidiu fundar o LibreOffice. O próprio BrOffice agora é LibreOffice. Isso – ao meu ver – é uma coisa boa, pois agora o poder não está mais nas mãos da Oracle, e sim da comunidade.

O lado técnico

Muito do que se ouve falar sobre ambos é antigo, e vem de estereótipos antigas, do MySQL 4.1 (a atual é 5.5) e do PostgreSQL 7.4 (a atual é 9.0). O MySQL possui agora vários recursos que antes não tinha, e o PostgreSQL está muito mais rápido. É comparado por muitos com o Oracle.

Mais de 75 recursos foram adicionados ao PostgreSQL de lá pra cá, resultado de um trabalho de vários anos para remover pontos chave que causavam problemas de escalabilidade. É possível também compactar e descompactar dados “on-the-fly”. A vantagem disso é que reduz a necessidade de acesso a disco, aumentando a performance.

O PostgreSQL possui apenas um sistema de armazenamento, e o MySQL possui vários. Você pode escolher de acordo com o tipo do projeto. Os mais utilizados no MySQL são InnoDB e MyISAM. O MyISAM é mais rápido que o sistema do PostgreSQL, mas tem um custo. Alguns recursos, como chaves estrangeiras e transações não estão disponíves. O InnoDB possui recursos para garantir mais integridade nos dados, mas é mais lento que o MyISAM. O PostgreSQL pode ser mais lento ou mais rápido que o MySQL utilizando o InnoDB, dependendo das configurações e recursos utilizados.

Trocando em miúdos

O MySQL pode ser sim uma boa opção em sistemas mais simples e bases menores, como um site ou um sistema que não tenha milhares de usuários concorrentes. Para sistemas mais complexos, que necessitam de maior integridade nos dados, que possuem milhões de linhas e vários TeraBytes de informação, o PostgreSQL pode ser a melhor opção. Mas lembre-se que em ambos existem várias configurações que podem ser feitas para melhorar vários aspectos. Se você lê em inglês, pode encontrar bastante informação aqui: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL e aqui http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009.