tiagopassos.com

Tem vários artigos na internet falando como realizar o procedimento, mas a maioria não funciona nas versões 9+, então, compartilho aqui como consegui fazer funcionar:

Usuário: readonly
Senha: readonly
Banco de Dados: foo

CREATE USER readonly  WITH ENCRYPTED PASSWORD 'readonly';
GRANT USAGE ON SCHEMA public to readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly;

-- repita o codigo abaixo para cada banco de dados

GRANT CONNECT ON DATABASE foo to readonly;
\c foo
-- o codigo abaixo concede o privilegio em novas tabelas geradas no banco "foo"
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO readonly;
GRANT USAGE ON SCHEMA public to readonly; 
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

Fonte: StackOverflow

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)

Algumas semanas atrás estava ministrando um treinamento de SQL Básico para os novos estagiários na empresa em que trabalho, e o conteúdo era formado basicamente por: SELECTs, INSERTs, UPDATEs e DELETEs. A criação de tabelas e bancos não fazia parte da ementa. Com isso me veio a seguinte dúvida:

Será que não existe nenhuma base de dados que possa ser usado como exemplo num caso como esses? Uma base que já venha preenchida – com dados fictícios – para que seja melhor compreendido o uso de SELECTs utilizando JOINS, por exemplo?

Foi aí que encontrei um projeto chamado Sakila, desenvolvido para o MySQL, que é exatamente o que eu estava procurando. Trata-se de uma base de dados de uma locadora fictícia, e contém filmes, atores, clientes, locações, funcionários e tudo mais que uma sistema de locadora teria direito. Bastante útil para o que eu precisava. Você pode baixar o Sakila original em inglês aqui e outras bases de exemplo aqui.

O único "problema" é que a estrutura do Sakila é toda em inglês. Na verdade, não é exatamente um problema, mas isso pode dificultar um pouco a compreensão de quem não é muito bom em inglês.

Para resolver isso, eu traduzi a estrutura da base, ou seja, nomes de tabelas, colunas e chaves. O projeto original também possui outros recursos, como triggers, views e procedures, mas como não era do meu interesse no momento, eu removi esses recursos da base.

Para fazer o download do Sakila com estrutura em português, clique aqui.

Futuramente pretendo criar versões do Sakila para outros SGBD's, como o PostgreSQL e SQL Server, mas por causa do meu pouco tempo, não posso precisar uma data. Se você tiver interesse de colaborar com outros usuários do blog e fazer uma versão diferente, terei prazer em colocar o link aqui. 🙂

Caso você precise da base de dados para algum trabalho acadêmico ou qualquer outro uso, fique à vontade para usar!