Saiba mais sobre a DigitanOcean: Adeus Amazon (AWS)… Olá DigitalOcean!

MySQL

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:


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. 🙂


Problemas ao exportar ou importar dados com o phpMyAdmin e o banco de dados MySQL

Se você está tentando exportar ou importar um arquivo grande, utilizando o phpMyAdmin e o banco de dados MySQL, e não está conseguindo, eu posso ter a solução.

Algumas vezes provedores bloqueam a exportação e importação de arquivos grandes com o phpMyAdmin e o MySQL. Muitas vezes nem precisa ser tão grande assim… Basta alguns megabytes e você já começa a ter problemas. Você simplesmente não consegue exportar ou importar dados.

Para resolver isso, uma solução é acessar diretamente a linha de comando e fazer o procedimento por lá. Uma tarefa que estava levando vários minutos para ser concluída, pode ser rapidamente executada em poucos segundos. Se você não tem acesso físico ao servidor, terá que verificar com seu provedor se é o SSH é liberado pra você, e só assim será possível fazer esse procedimento.

O procedimento foi testado no Ubuntu 10.04 LTS, mas deverá funcionar em qualquer distribuição Linux (e talvez até no Windows). Acesse o terminal (No Ubuntu, clique em Aplicativos / Acessórios / Terminal) e digite o seguinte:

Para importar dados

mysql -u usuario -p banco_de_dados < arquivo.sql

Substitua o que está em vermelho pelas informações corretas, correspondentes ao seu sistema. Será solicitada a senha em seguida. Se você está usando em sua máquina, onde você instalou o MySQL, possivelmente o usuário é root e a senha em branco.

Para exportar dados

mysqldump -u usuario -p banco_de_dados > arquivo.sql

Substitua o que está em vermelho pelas informações corretas, correspondentes ao seu sistema. Será solicitada a senha em seguida.

É isso! Espero que tenha ajudado.


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.


Perdi a senha do MySQL no Ubuntu! E agora!?

Não se desespere! Nessa vida tem jeito pra tudo. Somos humanos, e esquecemos senhas, certo? Então se isso aconteceu com você, tem uns comandos bem rápidos que vão te tirar do desespero. Aqui vai:

Acesse o Terminal (Aplicativos/Acessórios/Terminal):

sudo /etc/init.d/mysql stop
sudo mysqld --skip-grant-tables &
mysql -u root mysql
UPDATE user SET Password=PASSWORD('SUANOVASENHA') WHERE User='root'; FLUSH PRIVILEGES; exit;

Pronto. Agora você pode acessar o MySQL normalmente com sua senha nova.

Veja aqui como gerar uma nova senha do PostgreSQL no Ubuntu.

O procedimento foi testado no Ubuntu 10.04 LTS.


Acessar o MySQL pelo Prompt do Windows

Vez ou outra é necessário acessar o MySQL por linha de comando. Se você estiver no Windows, isso também é possível.

Clique no menu Iniciar, depois Todos os Programas (Windows 7). Em seguida clique em Acessórios, e depois em Prompt de Comando.

Se você tiver instalado o MySQL utilizando o Wamp ou XAMPP ele fica em uma pasta diferente de c:\mysql. Acesse – pelo prompt – a pasta onde fica o MySQL.

Se for o XAMPP, por exemplo, o executável fica em c:\xampp\mysql\bin

Depois que abrir a telinha preta, digite:

mysql -u <nome de usuário*> -p

Pronto. Agora é só digitar qualquer comando (SELECT, UPDATE etc.) que ele irá funcionar normalmente.

* o nome de usuário padrão, geralmente é root. Se a instalação é padrão, a senha está em branco, então é só apertar enter.


Converter de maiúsculas para minúsculas e vice-versa com o MySQL

Uma maneira bem simples de converter de maiúsculas para minúsculas, e vice-versa direto pelo banco de dados MySQL, sem utilizar de programação é utilizar as funções UPPER e LOWER do MySQL.

Exemplos:

De minúscula para maiúscula

SELECT upper( `nome` ) FROM `clientes`

De maiúscula para minúscula

SELECT lower( `nome` ) FROM `clientes`

Você também pode renomear os campos, para facilitar a exibição:

Exemplo:

SELECT upper( `nome` ) as `nome_do_cliente` FROM `clientes`

Se você quizer selecionar outros campos:

SELECT upper( `nome` ) as `nome_do_cliente`,`telefone`,`cidade` FROM `clientes`

A função UPPER é sinônimo da função UCASE e a função LOWER é sinônimo da função LCASE.


Realizando duas ou mais consultas com UNION e UNION ALL no MySQL

Algumas vezes não conseguimos obter os resultados que desejamos com uma só consulta no banco de dados. Para resolver esse problema existem os operadores UNION e UNION ALL.

Vamos a um exemplo:

(SELECT * FROM clientes WHERE idcidade = 1 LIMIT 3)
UNION (SELECT * FROM clientes WHERE idcidade = 5 LIMIT 3)
UNION (SELECT * FROM clientes WHERE idcidade = 8 LIMIT 3)

No exemplo acima ele vai retornar de uma só vez o mesmo que retornaria se você fizesse três selects diferentes.

Você também pode utilizar UNION ALL ao invés de UNION. A diferença é que ele vai retornar todos os resultados, inclusive as linhas repetidas.

Se não tiver como serem retornados registros duplicados, é mais vantagem usar o UNION ALL, que é mais rápido.

Observe que esse operador torna a consulta extremamente mais lenta, e ele só deve ser usados em casos bem específicos. Use com cautela.


Principais tipos de campos no MySQL

Muita gente tem dificuldade de escolher que campo usar para cada tipo de dado. Montei esse guia para facilitar o entendimento de quem tem dúvidas sobre isso.

Campos Numéricos
Alguns campos numéricos possuem a opção UNSIGNED. Isso quer dizer que o número não pode ser negativo. Por exemplo: o campo TINYINT com a opção UNSIGNED vai de 0 até 255, sem a opção UNSIGNED vai de -128 até 127.

A opção ZEROFILL completa o campo com zeros. Por exemplo: se você cadastrar ’65’ em um campo INT(5) – ou seja, inteiro com 5 dígitos – com a opção ZEROFILL habilitada, o MySQL irá cadastrar ‘00065’. Sem a opção ZEROFILL habilitada, o MySQL irá cadastrar ’65’.

  • TINYINT: Um número muito pequeno, de 0 até 255 (UNSIGNED) ou -128 até 127. Ocupa 1 byte.
  • SMALLINT: Um inteiro pequeno, de 0 a 65535 (UNSIGNED) ou -32768 até 32767. Ocupa 2 bytes.
  • MEDIUMINT: Um inteiro de tamanho médio, de 0 a 16777215 (UNSIGNED) ou -8388608 a 8388607. Ocupa 3 bytes.
  • INT ou INTEGER: Um inteiro de tamanho normal. De 0 a 4294967295 (UNSIGNED) ou -2147483648 a 2147483647. Ocupa 4 bytes.
  • BIGINT: Um inteiro grande. De 0 a 18446744073709551615 ou -9223372036854775808 a 9223372036854775807. Ocupa 8 bytes.
  • DECIMAL: Um número decimal. Para armazenar um valor monetário, por exemplo, você pode definir o tamanho dele como 8,2. Isso quer dizer que ele poderá ter 8 dígitos à esquerda da vírgula, e duas casas decimais à direita da vírgula. O campo é armazenado como string, então não deve ocorrer nenhuma perda de precisão (arredondamento).
  • DATE: Data no formato ‘AAAA-MM-DD’. Entre ‘1000-01-01’ e ‘9999-12-31’.
  • DATETIME: Combinação de data e hora no formato ‘AAAA-MM-DD HH:MM:SS’. Entre ‘1000-01-01 00:00:00’ e ‘9999-12-31 23:59:59’.
  • TIME: Hora no formato ‘HH:MM:SS’. A faixa é entre ‘-838:59:59’ e ‘838:59:59’.
  • YEAR: Ano com 2 ou 4 dígitos (padrão 4 dígitos).
  • ENUM: Uma enumeração. Exemplo de uso: você tem um campo chamado “ativo” que possui apenas duas opções (0 e 1). Pode ter até 65535 valores diferentes.

Campos String (texto)

  • VARCHAR: String com tamanho entre 1 e 255 caracteres.
  • CHAR: String com tamanho entre 1 e 255 caracteres. Para campos com tamanho fixo (CPF, CEP etc.) é mais vantagem usar o CHAR, porque ele ocupa um byte a menos que o VARCHAR. Por exemplo: você vai cadastrar o valor “abcde” em um campo CHAR(5), ele vai ocupar 5 bytes, se você cadastrar em um VARCHAR(5), ele vai ocupar 6 bytes, porém se você cadastrar o valor “ab” em um campo CHAR(5) ele vai ocupar os mesmos 5 bytes, e o VARCHAR(5) vai ocupar 3 bytes (1 byte a mais do que a quantidade de caracteres).
  • TINYTEXT ou TINYBLOB: String com até 255 bytes.
  • TEXT ou BLOB: String com até 65535 bytes ou 64KB.
  • MEDIUMTEXT ou MEDIUMBLOB: String com até 16777215 bytes ou 16MB.
  • LONGBLOB: String com até 4294967295 bytes ou (4GB).

Conectar ao MySQL e escolher um banco de dados com o PHP

Exemplo das funções utilizadas para conectar com o MySQL e escolher um banco de dados.

<?php
mysql_connect("localhost", "USUARIO", "SENHA") or die(mysql_error());
mysql_select_db("BANCO_DE_DADOS") or die(mysql_error());
?>

Algumas vezes o nome do servidor pode ser diferente, mas na grande maioria se usa localhost mesmo.


  • Redes Sociais

    Facebook  Twitter
  • Projetos Paralelos

  • 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