Tag: banco de dados

Criar usuário somente leitura no PostgreSQL 9+

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


Uber migra do PostgreSQL para o MySQL

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:

Outro artigo comentando o artigo do Uber:


Descoberta falha de segurança no PostgreSQL

Foi liberada hoje uma atualização de segurança do PosgreSQL para todas as versões ativas (8.4, 9.0, 9.1 e 9.2). A correção feita trata especificamente um bug de alto risco para a integridade do sistema de arquivos. É extremamente recomendado que as atualizações sejam realizadas o quanto antes.

O bug é o seguinte: se alguém abrir uma conexão com o seu servidor, e utilizar um nome de banco de dados que começa com "-", o sistema de arquivos pode ser danificado. O caso é mais grave para servidores que estão expostos à internet sem a devida proteção de Firewall, o que reforça a importância de se fechar o acesso ao servidor e deixar apenas as portas necessárias, para os IP's necessários.

Segundo o site Database Soup, existem 120 mil servidores no mundo expostas à essa falha e em situação de risco.

Fonte: http://www.postgresql.org/about/news/1456/


Adicionar zeros à esquerda em um código no PostgreSQL com a função LPAD

Você tem uma tabela nos PostgreSQL quem tem vários códigos, sendo alguns com dois caracteres, outros com três, e por aí vai. Mas como fazer para uniformizar a quantidade de caracteres, ou seja, deixar todos os códigos com a mesma quantidade de números, adicionando zeros à esquerda? Basta utilizar a função LPAD do PostgreSQL. Vamos ao exemplo:

select 
   lpad(cast(cod_curso as varchar),4,'0') as cod_curso 
   from cursos

No exemplo acima, o código do curso que possui 3 caracteres, por exemplo: 125, virou 0125. O código do curso com 2 caracteres, por exemplo: 15, virou 0015. E por aí vai.

Você pode fazer os testes utilizando o banco de testes.

Saiba mais sobre o LPAD aqui e aqui.


Sakila: Banco de Dados MySQL para Estudo/Treinamento com Estrutura em Português

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!


Que tal um curso de Introdução a Bancos de Dados na Universidade de Stanford GRÁTIS?

É isso mesmo. A Universidade de Stanford – de onde saíram empresas como a SUN (antiga dona do Java), além de Yahoo, HP, Cisco, Netscape e Google – está disponibilizando gratuitamente um curso de Introdução a Bancos de Dados. O curso será ministrado por Jennifer Widom, Ph.D. em Ciência da Computação na Cornell University em 1987, que ministra a disciplina na Universidade.

Além disso, você terá direito a um certificado emitido pelo instrutor (infelizmente não é emitido pela Universidade), onde estará registrado seu andamento. Dá uma boa levantada no currículo, né não?

Outros dois cursos também estarão disponíveis: Introdução à Inteligência Artificial e Aprendizagem de Máquina. Ambos também gratuitos.

Clique aqui para se inscrever no curso de Introdução a Bancos de Dados.

Os cursos serão ministrados no período de 10 de Outubro a 16 de Dezembro.


MySQL ou PostgreSQL? Eis a questão!

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.



Backups no WordPress com o EZ Backup

File Not FoundMuita gente não dá a importância necessária, mas backup é essencial. Seu site no WordPress pode se perder completamente por vários motivos, como uma falha no servidor, por exemplo, e é importantíssimo ter uma cópia de segurança se isso acontecer.

Procurei plugins de backup do WordPress e demorei a encontrar um que me agradasse. Muitos só fazem backup do banco de dados, mas o backup das imagens, anexos, e do sistema com seus plugins também é essencial. Para fazer isso tudo, de forma bem rápida, recomendo o WordPress EZ Backup (Easy Backup, ou Backup Fácil, em português). Pode ser necessário acessar o servidor FTP para configurar o Plugin. Se você não sabe como fazer isso, pode entender melhor aqui.

Depois de instalado e configurado, o plugin salva uma cópia completa do seu blog na pasta do servidor e envia outra para o seu e-mail. Para instalar, vá na página Plugins/Adicionar Novo e procure por WordPress EZ Backup, clique em install e em seguida Ativar. Feito isso aparecerá no menu a opção EZ Backup, clique nela e você será redirecionado para a página de configuração do plugin.

WP-EZ-Backup

Agora vou mostrar o que significa cada campo desses, utilizando os números em vermelho na imagem. O plugin pega algumas informações do servidor e já coloca ao lado, pra te ajudar a preencher.

  1. Pasta da qual será feita o backup, você coloca a pasta onde está o WordPress.
  2. Nome do banco de dados;
  3. Nome do arquivo que será criado. Ele acrescenta a data no final;
  4. Pasta onde será salvo o arquivo de backup no servidor. É recomendado um nível acima da pasta pública. Se você não sabe que pasta é essa, pode perguntar no seu provedor. Geralmente é a pasta onde fica o diretório public_html;
  5. Email que receberá a notificação que o backup foi concluído;
  6. Ative esta opção se quiser receber por email o arquivo de backup;
  7. Endereço do servidor SQL;
  8. Nome do usuário do servidor SQL;
  9. Senha do servidor SQL.

Os valores para colocar nos campos 2, 7, 8 e 9 você pode descobrir no arquivo wp-config.php. Você pode acessar o FTP e baixar esse arquivo para o seu computador. É provável que ele esteja dentro da pasta public_html. Abra o arquivo, você pode entender como verificar os dados no exemplo abaixo:

  • define(‘DB_NAME’, ‘teste‘); // Esse é o nome do banco de dados (2)
  • define(‘DB_HOST’, ‘localhost‘); // Endereço do servidor SQL (7)
  • define(‘DB_USER’, ‘usuario‘); // Nome do usuário do servidor SQL (8)
  • define(‘DB_PASSWORD’, ‘123456‘); // Senha do servidor SQL (9)

Depois de preencher tudo, clique em Save Settings. Para criar o backup clique em Create Backup. Se você quizer ver se houve algum erro, clique em View Error Log. Para agendar backups automáticos – é necessário ter uma noção de como funciona o Cron, do Linux – clique em EZ Backup/Scheduling. No botão “Check for Cron Daemon” é possível descobrir se seu provedor dá suporte ou não ao Cron. Você pode escolher o dia da semana e a hora, que ele te retorna a linha para adicionar ao cron, bastando clicar em “Generate Command”.

É isso. Faça seus backups com freqüência. Se você atualiza o blog todo dia, recomendo um backup por dia. Assim você não passará por nenhum aperto se seu provedor te decepcionar.


Saiu a edição 22 da Revista Espírito Livre!

Revista Espírito Livre - Edição 22

A Revista Espírito Livre é uma publicação gratuita sobre software livre. A revista é liberada todos os meses em PDF no site. Na edição 22, o tema é “Software Livre nas Empresas”, e entre outras coisas fala sobre como o software livre já é uma realidade em grande parte das empresas, e aquelas que, dizem não usar, muito provavelmente acabam usando, seja na hospedagem de seu site, seja no framework utilizado para criar uma solução web, seja para navegar, já que a própria Internet tem como pilares, softwares de código-aberto.

Além disso, a edição apresenta várias outros artigos que ajudam a compor o tema do mês. Albino Biasutti apresenta um pequeno case de sucesso de implantação de software livre em uma empresa hospitalar, Estefânio Luiz Almeira fala sobre o MySQL e como ele pode ser uma boa solução empresarial, no que diz respeito a Sistemas de Gerenciamento de Banco de Dados. Evaldo Júnior, que andava sumido, mas que retoma suas contribuições junto a revista, fala sobre um case de implantação de software livre em uma micro empresa. Gilberto Sudré, deixa claro em seu artigo, que o software livre já está maduro para o mercado.

Baixe a revista de graça aqui!


  • Publicidade

  • Redes Sociais

    Facebook  Twitter
  • Estatísticas

    Page Views (desde março de 2010):

    Estatísticas detalhadas
  • Novidades por e-mail!

    Digite seu e-mail:


    Fique tranquilo. Seu e-mail não será usado para outros fins, e você poderá se descadastrar quando quizer.

    Eu!

    Tiago Passos
    Todo o conteúdo desse site esta licenciado sob a licença Creative Commons 3.0 (CC BY 3.0). Você pode copiar e modificar o conteúdo desde que cite o autor.
    iDream theme by Templates Next | Powered by WordPress