Arquivo da tag: mysql

Versão 5.5.23 do MariaDB é liberada e traz melhorias de desempenho

Fonte: IMasters

Com informações de The H

A versão 5.5.12 do MariaDB, um substituto drop-in para o MySQL, foi publicada pelos desenvolvedores no Monty Program. O primeiro release estável para o banco de dados open source inclui melhorias de desempenho e a adição de novas funcionalidades em relação ao MySQL 5.5.23, no qual foi baseado.

De acordo com os desenvolvedores, a funcionalidade thread pool agora está significativamente mais eficiente, tornando-se comparável à mesma funcionalidade de fonte fechada no MySQL Enterprise. Outras mudanças incluem uma opção @@skip_replication e atualizações para o mysql_real_connect(), assim como a adição de um novo argumento INSTALL SONAME e otimizações em LIMIT ROWS EXAMINED.

Os desenvolvedores ressaltaram que, como o MariaDB 5.5.23 inclui o MariaDB 5.3.6, a atualização corrige um problema sério de segurança que poderia permitir que um usuário se conectasse com uma senha inválida em certas circunstâncias. Usuários com versões mais antigas são alertados para realizarem a atualização o mais rápido possível.

Mais detalhes sobre a nova versão, incluindo uma lista completa de mudanças, podem ser encontrados neste link, nas notas de lançamento e no change log. O MariaDB 5.5.23 está disponível para download para sistemas de 32 e de 64 bits.

O que é e como usar o MySQL?

Fonte: Pedro Pisa/TechTudo


O MySQL é um sistema gerenciador de banco de dados relacional de código aberto usado na maioria das aplicações gratuitas para gerir suas bases de dados. O serviço utiliza a linguagem SQL (Structure Query Language – Linguagem de Consulta Estruturada), que é a linguagem mais popular para inserir, acessar e gerenciar o conteúdo armazenado num banco de dados.

Na criação de aplicações web abertas e gratuitas, o conjunto de aplicações mais usado é o LAMP, um acrônimo para Linux, Apache, MySQL e Perl/PHP/Python. Nesse conjunto de aplicações, inclui-se, respectivamente, um sistema operacional, um servidor web, um sistema gerenciador de banco de dados e uma linguagem de programação. Assim, o MySQL é um dos componentes centrais da maioria das aplicações públicas da Internet.

O sistema foi desenvolvido pela empresa sueca MySQL AB e publicado, originalmente, em maio de 1995. Após, a empresa foi comprada pela Sun Microsystems e, em janeiro de 2010, integrou a transação bilionária da compra da Sun pela Oracle Corporation. Atualmente, a Oracle, embora tenha mantido a versão para a comunidade, tornou seu uso mais restrito e os desenvolvedores criaram, então, o projeto MariaDB para continuar desenvolvendo o código da versão 5.1 do MySQL, de forma totalmente aberta e gratuita. O MariaDB pretende manter compatibilidade com as versões lançadas pela Oracle.

Como usar o MySQL

Para utilizar o MySQL, é necessário instalar um servidor e uma aplicação cliente. O servidor é o responsável por armazenar os dados, responder às requisições, controlar a consistência dos dados, bem como a execução de transações concomitantes entre outras. O cliente se comunica com o servidor através da SQL. A versão gratuita do MySQL é chamada de Edição da Comunidade e possui o servidor e uma interface gráfica cliente.

Interface inicial do MySQL Workbench

O servidor deve ser instalado e configurado para receber conexões dos clientes. No MySQL, o principal cliente é a interface gráfica cliente fornecida pela Oracle, denominada MySQL Workbench. Através do MySQL Workbench, pode-se executar consultas SQL, administrar o sistema e modelar, criar e manter a base de dados através de um ambiente integrado. O MySQL Workbench está disponível para Windows, Linux e Mac OS.

Na interface de modelagem de base de dados do MySQL Workbench, pode-se definir as entidades da base de dados, seus atributos e relacionamentos. Em banco de dados, deve-se definir configurações importantes para os bancos de dados, como as chaves primárias e estrangeiras e os atributos que devem ser indexados. Todas essas configuras são definidas nessa interface.

Interface de modelagem da base de dados do MySQL Workbench

Na figura abaixo, apresenta-se a interface de administração do aplicativo, a qual consiste de informações sobre o status do sistema, como uso de processamento, memória e conexões simultâneas, e de configurações do sistema de gerenciamento e das bases de dados.

Configurações do sistema gerenciador consistem, entre outras mais complexas, da porta TCP, que deve ser conectada, e da pasta onde os arquivos das bases de dados são salvos no disco. As configurações específicas das bases de dados consistem na codificação dos dados, nas permissões de acesso, por exemplo.

Interface de administração do MySQL Workbench

No editor genérico de consultas, ilustrado na imagem abaixo, o administrador pode executar consultas para buscar informações especificas ou testes. Basta inserir a consulta SQL, na parte superior da janela, e os resultados são exibidos na guia “Output” da metade inferior da janela. Na guia “Overview”, o administrador pode obter os nomes das tabelas, visões e rotinas de cada base de dados criada no sistema.

Editor genérico de consultas SQL do MySQL Workbench

MySQL 5.6.2 introduz a interface NoSQL

Fonte: IMasters

Com informações de The H

A Oracle lançou a versão 5.6.2 do MySQL, que ganhou melhorias no recurso de replicação e a capacidade de passar do framework SQL para um acesso mais rápido a dados e para performace parecida com NoSQL.

Reagindo às demandas dos clientes para a melhoria da velocidade de transação, o MySQL 5.6.2 introduz uma interface NoSQL usando a API memcached, que permite aos usuários acessar diretamente o mecanismo de armazenamento InnoDB, ignorando completamente o SQL, mantendo a compatibilidade com o modelo de banco de dados relacional. Os recursos do NoSQL foram originalmente vistas em um “laboratório instantâneo” em abril de 2011. A replicação também tem recebido vários novos recursos no MySQL 5.6.2, incluindo melhorias de desempenho e melhorias de integridade de dados, tais como novas replicações de checksums e a recuperação automática de escravos de banco de dados com falhas.

Mais informações sobre o lançamento você encontra aqui. O software experimental está licenciado sob a GPLv2 e pode ser baixado do site do MySQL Labs. Como acontece com todo o software experimental, os usuários são lembrados de que o objetivo é usá-los em teste e não deve ser usados em ambientes de produção.

Twitter abre código de melhorias que promoveu no MySQL

Fonte: IMasters

Com informações de The H

O Twitter anunciou que está abrindo o código do trabalho que fez para melhorar o MySQL em seus sistemas de produção. O microblog é um grande usuário do MySQL – utiliza-o para timeline, dados do usuário, gráfico de interesse e armazenamento de tweets – e vem adaptando-o às suas necessidades.

As mudanças incluem tornar o MySQL mais monitorável ao exportar mais informações da engine de armazenamento InnoDB e fazer com que o MySQL se torne mais previsível ao alocar buffers na inicialização em máquinas com muita quantidade de memória, além de melhorar intervalos e cancelamentos em consultas.

Outras modificações otimizam o MySQL para sistemas baseados em SSD ao mudar o comportamento para reduzir o número de escritas no disco, o que deveria melhorar a expectativa de vida dos drives SSD. Além disso, o Twitter desenvolveu uma técnica para exportar e restaurar o pool buffer InnoDB, que é usado como parte de suas ferramentas de construção para fornecer restaurações contínuas para sistemas.

As alterações foram publicadas no GitHub sob a licença New BSD e estão documentadas. Além disso, o histórico de mudanças está disponível.

Atualização do MySQL Cluster traz melhoria de desempenho

Com informações de The H

Fonte: IMasters

A Oracle liberou a versão 7.2 do MySQL Cluster, que aumenta consideravelmente a velocidade do banco de dados em rede. Segundo a empresa, a funcionalidade “Adaptive Query Localisation” permite que o cluster responda a consultas mais de 70 vezes mais rápido.

A ideia por trás dessa funcionalidade é que, em vez de deixar todo o processamento de consultas para o servidor central, os nós de dados individuais agora possuem inteligência suficiente para responder a partes das consultas. Isso reduz a quantidade de dados que é enviada para o servidor. A tecnologia é voltada para aumentar a velocidade de consultas que combinam várias tabelas usando JOIN.

Além disso, a memcached API também foi adicionada à nova versão. Isso permite que bancos de dados sejam endereçados como tabelas relacionais através do SQL e como dados key/value no NoSQL. Agora, clusters em diferentes locais físicos podem ser interconectados, e as tabelas comuns de privilégios do usuário foram consolidadas.

O MySQL Cluster 7.2.4 está disponível para download para várias distribuições Linux, Windows e Solaris. Um vídeo sobre o MySQL Cluster pode ser assistido aqui.

Uma tabela de relacionamento de muitos para muitos – resolvendo o problema de relação de exclusão

Começarei definindo o relacionamento de Muitos para Muitos MySQL (Experts podem pular para o próximo parágrafo).

O que é um relacionamento de Muitos para Muitos MySQL

Um relacionamento de Muitos para Muitos MySQL é um relacionamento que é multi-valorado em ambas as direções.

Esse tipo de relacionamento é auxiliado pelo uso de uma tabela de ligação. Por exemplo, uma Pergunta (Question) pode ter mais de uma Categoria (Categorie), e uma Categoria pode ter mais de uma Pergunta.

CREATE TABLE link (
   Question_id int unsigned NOT NULL,
   Category varchar(20),
   PRIMARY KEY  (`Question_id `,` Category`),
   KEY `category_question` (`Category`,`Question_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

+-------------+---------------+
| Question_id | Category      |
+-------------+---------------+
|  1          | Animals       |
|  1          | Business      |
|  1          | Vehicles      |
|  2          | Animals       |
|  3          | Business      |
|  3          | Vehicles      |
|  4          | Animals       |
|  4          | Vehicles      |
|  5          | Business      |
+-------------+---------------+

Essa é uma tabela de ligação chamada link, que nos ajuda a juntar relacionamentos entre as duas tabelas, Perguntas e Categorias.

Como podemos ver, essa tabela está refletindo um relacionamento de muitos para muitos (a pergunta 1 tem as categorias Animais, Negócios e Veículos – ‘Animals, Business and Vehicles’. A categoria Animais tem as perguntas 1, 2 e 4).

O que é o problema de relação de exclusão?

Dada uma tabela de relacionamento de muitos para muitos, como você é capaz de selecionar linhas que não tenham um relacionamento específico? Em termos do exemplo pergunta-categoria, essa pergunta é traduzida no seguinte:

Como você consegue selecionar (digamos as primeiras mil) perguntas que não têm a categoria Negócios. No nosso exemplo, queremos somente que os Question_id 2 e 4 sejam retornados.

Uma solução ruim

Uma solução ruim seria:

SELECT
DISTINCT Question_id
FROM
link
WHERE
Category <> "Business"
ORDER BY
Question_id DESC
LIMIT
1000;

Essa consulta irá funcionar se uma pergunta somente for permitida uma categoria. No nosso caso, como uma pergunta tem pelo menos uma categoria, desde que uma pergunta esteja associada à outra categoria que não seja Business, ela retornará. Portanto, o resultado dessa consulta é Question_id: 1, 2, 3, e 4 , que não satisfaz a relação de exclusão.

Primeira solução

SELECT
DISTINCT Question_id
FROM
link
WHERE
Question_id NOT IN (SELECT Question_id FROM link WHERE Category="Business")
ORDER BY
Question_id DESC
LIMIT
1000;

A consulta dependente interna (SELECT Question_id FROM link WHERE Category<>”Business”) tem um problema de desempenho – ela será executada pela menos mil vezes e, se ela não for rápida, os atrasos são multiplicados por um número que é, no mínimo, 1.000. Quando o método de acesso (o type field no EXPLAIN statement output) é index_subquery, um index de pesquisa de otimização é usado e um monte de sobrecarga é evitada.

Quando é ampla, a sub query está sendo reexecutada, como é feita para cada linha. Você deve verificar seus . You must check your EXPLAIN details.

Segunda solução

CREATE TEMPORARY TABLE not_wanted_Question_id (
UNIQUE KEY(Question_id)
) ENGINE=MEMORY
SELECT
DISTINCT Question_id
FROM
link
WHERE
Category="Business";

SELECT
DISTINCT link.Question_id
FROM
link
LEFT JOIN
not_wanted_Question_id nw ON (link.Question_id = nw.Question_id)
WHERE
nw.Question_id is NULL
ORDER BY
link.Question_id DESC
LIMIT
1000;

DROP TABLE not_wanted_Question_id;

O problema de execução de consultas internas múltiplas é reduzido a uma pesquisa uma única chave dentro de uma tabela na memória, que é basicamente uma pesquisa hash e é muito rápida. No entanto, a construção de perguntas indesejadas pode sair caro para tabelas grandes. Note que criar a tabela, selecionar e então soltar devem ser todos feitos juntos, para toda vez que você precisar dos resultados.

Terceira solução (a melhor em desempenho)

Esta é minha melhor solução para esse problema e com melhor desempenho para tabelas pesadas:

SELECT
 Question_id ,
 SUM(IF (Category="Business", 1, 0)) AS exclude
 FROM
 link
 GROUP BY
 Question_id DESC
 HAVING
 exclude=0
 LIMIT
 10000;

Isso funciona muito bem no nosso caso, porque temos um index no Question_id e colunas de categorias. A função SUM está contando o número de ocorrências indesejadas de categoria para cada Question_id na ordem e o statement Having está filtrando-os.

O LIMIT termina os cálculos assim que chega no número limite.

Texto original em ingles de Hazan Ilan, disponível em http://www.mysqldiary.com/a-many-to-many-relationship-table-solving-the-exclude-relation-problem/

Fonte: Hazan Ilan/IMasters

O modelo de dados do Joomla

Olá pessoal. Neste artigo vou apresentar mais uma análise do modelo de dados utilizado em um CMS (Content Management System). Desta vez apresentarei o modelo de dados do Joomla, um dos CMSs mais populares.

Há algum tempo atrás escrevi um artigo sobre o modelo de dados do WordPress aqui no iMasters. Desta vez vou analisar e comentar o modelo de dados do Joomla, outro CMS que está se tornando muito popular aqui no Brasil não apenas para a construção de blogs, mas também para a criação de web sites inteiros e complexos.

Assim como o WordPress, o Joomla pode ser utilizado basicamente de duas formas:

Através da contratação e utilização de um hosting especializado que hospedará o site;

Através do download e instalação do Joomla disponível no site oficial do Joomla. Há também uma forte comunidade de usuários brasileiros representados no site oficial do Joomla no Brasil.

A utilização do Joomla através da contratação de um hosting vai depender das configurações que o serviço de hospedagem fornece.

É comum encontrar painéis de controle e outras interfaces que facilitam tanto a administração como a criação de conteúdo. Contudo, nestas situações geralmente o ambiente está montado e não é preciso interagir diretamente com o banco de dados.

Já a segunda forma de utilização envolve o download, instalação e configuração do Joomla. Neste contexto é preciso conhecimento técnico da instalação do Joomla e suas dependências, como o servidor de banco de dados MySQL, o PHP e o servidor Web escolhido.

Este artigo se concentra nos detalhes técnicos envolvidos no banco de dados. O público alvo deste artigo são profissionais que precisam lidar com instalação, configuração e manutenção do Joomla e não para quem apenas o usa para gerenciar conteúdo.

É razoável admitir que a maioria dos usuários não precise conhecer o modelo de dados devido à facilidade do uso de painéis administrativo e outras interfaces que permitem a publicação de conteúdo neste CMS. Porém, administradores, DBAs, desenvolvedores de plug-ins e quem resolve problemas de desempenho ou integração com o Joomla devem conhecer bem seu modelo de dados.

Uma vez que já foram explicadas as duas formas de se utilizar o Joomla vamos ao modelo de dados que este CMS utiliza.

A Figura 1 apresenta o modelo de dados (isto é, as tabelas e seus tipos de dados) utilizados pelo Joomla 1.6 e modelados na ferramenta de código aberta DBDesigner disponível em diversas plataformas.

Figura 1. Modelo de dados do Joomla 1.6 no DBDesigner

Já a Figura 2 apresenta o mesmo modelo de dados da Figura 1, porém modelado utilizando a ferramenta livre de modelagem e administração chamada MySQL Workbench.

Figura 2. Modelo de dados do Joomla 1.6 no MySQL Workbench.

Os modelos da Figura 1 e da Figura 2 não foram produzidos por mim. O crédito vai para Torkil Johnse, que disponibilizou estes modelos gratuitamente no seu blog nos formatos do MySQL Workbench(MWB), PNG, PDF e SVG.

Nota: as figuras representam um modelo de dados levemente modificado em relação ao modelo original, como o próprio Torkil comenta em seu blog. As principais diferenças são a mudanças de alguns tipos de dados e a colocação de relacionamentos, uma vez que o MySQL com MyISAM não os suporta. Também destaco que o modelo da Figura 2 não apresenta nenhuma informação sobre os índices das tabelas.

Oficialmente não encontrei nenhuma página que contém informações sobre este modelo inclusive com detalhes das tabelas e suas colunas. Mas encontrei uma página apresenta um fraco dicionário de dados sem muitas informações detalhadas a respeito de certas características do modelo como, por exemplo, justificativas a respeito dos tipos de dados. Acesse a página que contém este dicionário de dados simplificado para a versão 1.5.

Assim como o WordPress, o Joomla não possui um arquivo contendo todos os comandos SQL necessários para a criação do banco de dados, ou seja, é preciso fazer uma chamada a um arquivo .php após as configurações de acesso a banco de dados no painel administrativo.

Antes de começar a análise do modelo é preciso dizer que oficialmente o Joomla só pode ser instalado no MySQL e/ou a extensão MySQLi. Isso quer dizer que se a empresa já possui outro banco de dados, como o PostgreSQL, SQL Server ou Oracle por exemplo, é preciso configurar um ambiente multi-banco, o que possui implicações para quem administra os servidores.

Existem alguns esforços da comunidade para permitir que o Joomla suporte outros bancos de dados, porém estes esforços ainda não foram integrados oficialmente ao projeto. Para mais informações sobre o suporte a outros bancos de dados no Joomla recomendo os seguintes links:


De forma similar ao que acontece no WordPress, o modelo de dados do Joomla também não contém chaves estrangeiras. O motivo pela ausência de chaves estrangeiras provavelmente é por que ele foi criado utilizando o engine MyISAM do MySQL ao invés do engine InnoDB. Aqui repito o que já havia falado quando analisei o modelo de dados do WordPress:

O MySQL apresenta a criação de chaves estrangeiras com o engine InnoDB a partir da versão 3.23.43b. O MySQL já está na versão 6, porém há o famoso problema de compatibilidade com as base legada. Provavelmente escolheu-se o MyISAM por facilidade e por motivos de desempenho, o que NÃO quer dizer que um banco de dados com o InnoDB não possa ser ajustado para ter uma desempenho aceitável.

Sem entrar em uma discussão mais profunda, em geral muitas pessoas advogam que o engine MyISAM possui melhor desempenho que o InnoDB, porém este último possui suporte a transações, integridade e outros recursos que o MyISAM não possui.

A falta de chaves estrangeiras quer dizer que o relacionamento entre algumas tabelas não é mantido pelo banco de dados e sim pela aplicação. Isso permite que hajam dados inconsistentes no banco de dados como, por exemplo, um comentário de um blog que não tem nenhum post associado.

Apesar deste cenário ser fictício e ocorrer apenas quando alguém altera os dados diretamente pelo banco de dados e não pela opção de criação de conteúdo, esta possibilidade de inconsistência pode gerar problemas, principalmente quando se fala em migração de dados e segurança.

Existem várias características e pontos do modelo do Joomla que podem ser analisados. O próprio Torkil Johnsen já apresentou diversos aspectos do modelo que ele crê que podem ser melhorados no artigo chamado The Joomla database schema smells.

Os principais pontos que ele destaca são a falta de padronização e problemas de nomenclatura, tipos de dados, normalização e falta de completude do modelo. Concordo com muitos dos pontos levantados pelo Torkil e aqui vou colocar algumas considerações minhas e, quando possível, realizar pequenas comparações com o modelo de dados do WordPress.

O modelo do Joomla possui mais de 30 tabelas divididas em grupos como publicação de conteúdo, componentes, menus, templates e outros. Essas divisões foram destacadas em retângulos com nomes na Figura 1.

Já o WordPress é mais enxuto e contém 11 tabelas. Existe uma correlação entre a quantidade de tabelas e colunas de um modelo e a sua complexidade, especialmente em aplicações simples que não estão associadas a toneladas e toneladas de requisitos e casos de uso com diferentes tipos de usuários.

Ou seja, quanto mais tabelas/colunas em um modelo de dados provavelmente ele vai ser mais complexo de ser compreendido, vai dificultar tarefas de importação/exportação e possui e tendência de introduzir complexidade desnecessária.

A principal tabela do modelo do Joomla possui o sufixo _content e é responsável pelo armazenamento de informações sobre o conteúdo (como posts em um blog). Esta tabela concentra muita informação nela mesma e possui quase 30 colunas. Obviamente, nem todas as colunas são preenchidas quando se cria um novo post e muitas destas colunas possuem valores que claramente poderiam ser mais bem aproveitados se estiverem em outra tabela.

Por exemplo, a dupla de colunas publish_up e publish_down, ambas do tipo DATETIME, armazenam a data que o post foi publicado e a data em que ele foi retirado do ar. Porém somente duas datas são armazenadas e não há como armazenar o histórico de mais de uma data de publicação e retirada do post. Esta característica se repete ao longo de diversas outras tabelas do modelo.

Outro ponto que me chamou a atenção foi a falta de tipos de dados booleanos, que armazenam valores 0/1 ou VERDADEIRO/FALSE ou TRUE/FALSE. Em muitas tabelas existem colunas que, aparentemente, poderiam se beneficiar do tipo de dados booleano como, por exemplo, a tabela _contact_details, que contém uma coluna chamada published do tipo de dados TINYINT(1).

Além disso, destaca-se também o uso em excesso de colunas com o tipo de dados TEXT, algo que permite o armazenamento de dados limitado apenas pelos recursos do servidor e não por um número fixo de caracteres.

O uso em excesso de colunas do tipo TEXT pode eventualmente se tornar um problema devido à grande quantidade de caracteres armazenados e à necessidade de backups específicos por tabelas. Sem contar que a indexação e pesquisa para este tipo de dados devem ser especiais, algo que não é tratado no Joomla diretamente.

Do ponto de vista de modelagem, em algumas situações o modelo atende a certos requisitos relativamente bem, como é o caso do gerenciamento de usuários, grupos e permissões.

Por outro lado, algumas tabelas deveriam ser implementadas como plug-ins ou extensões e não diretamente no modelo padrão, como é o caso do gerenciamento de avaliação (rating) de um post cujos dados são armazenados na entidade _content_rating.

Outro exemplo de tabelas que seriam mais bem aproveitadas em plug-ins ou extensões está relacionado com a criação de enquetes (polls) cujos dados são armazenados nas tabelas_polls, _polls_menu e _polls_data.

Outro aspecto que me chamou à atenção no modelo foram as tabelas responsáveis pelo armazenamento de informações de propaganda (_banner, _bannerclient e _bannerfinish) que provavelmente vieram como resquício do modelo do banco de dados do Mambo, projeto na qual o Joomla se originou.

Atualmente o modelo de patrocínio em sites evoluiu muito em relação aos antigos banners e creio que estas tabelas acabaram ficando no esquecimento devido à funcionalidades e requisitos de campanhas com links patrocinados e integração com programas de afiliados.

Apesar de não ser difícil compreender o modelo uma vez que se acostume a ele, em algumas situações fica estranho não contar com a nomenclatura e termos já tradicionais.

Por exemplo, em nenhuma tabela/coluna existe o termo comentário. No modelo de dados esta forma de interação do usuário com o post é chamada de mensagens. Já a tradicional forma de taxonomia apresentada por tags é representada por seções e categoria em um post. Já template é utilizado estritamente para menus e não faz referência direta à forma de customização do layout do site.

Novamente, assim como no WordPress, o modelo de dados do Joomla não possui nenhuma outra integridade de domínio ou stored procedure que faça restrição ao que é inserido no banco. Apesar disso não ser obrigatório, esta prática abre margem para problemas como SQL Injection onde um usuário malicioso pode tentar invadir o site por meio de caracteres especiais.

Além disso, a falta desta integridade pode permitir dados que invalidem a aplicação como, por exemplo, colocar o valor -2 na coluna count da tabela _categories. Há também algumas colunas de tabelas onde o valor NULL é permitido, tornando necessária uma checagem adicional na aplicação.

Enquanto alguns podem argumentar que isso é responsabilidade da aplicação não é raro encontrar bancos de dados com este tipo de integridade de domínio implementada, fornecendo assim mais uma camada de segurança e consistência de dados.

Em resumo pode-se dizer que o modelo do Joomla é robusto e atende à sua necessidade, porém é um modelo que carrega muito do projeto Mambo. O destaque vai para o foco de armazenar no banco de dados informações tanto de conteúdo como de usuários, configurações, comentários, avaliações, menus, etc.

Com certeza este modelo pode ser melhorado nos aspectos de nomenclatura, padronização, tipagem, normalização e outros. E esta melhoria é responsabilidade da comunidade de desenvolvedores e usuários do Joomla. Infelizmente, melhorias profundas no banco de dados requerem tempo conforme o projeto vai ficando cada vez mais maduro.

Apesar destas ressalvas, o Joomla é um bom CMS que pode ser utilizada para montar muitos projetos e sites interessantes. Obviamente, ele precisa evoluir e continuar a inovar no aspecto de funcionalidades, customização e usabilidade.

Sugiro aos desenvolvedores e à comunidade que procurem também aprimorar o seu modelo de dados, o que pode trazer inúmeros benefícios à ferramenta tornando-a cada vez melhor.

Um grande abraço e até a próxima.

Fonte: Mauro Pichiliani/joomlaclube

Além de MySQL – Ramificando o banco de dados popular

Embora MySQL seja um dos programas mais populares, muitos desenvolvedores sentiram necessidade de ramificá-lo em outros projetos, cada um oferecendo sua própria especialidade. Essa necessidade, junto com o medo de que a Oracle irá desacelerar o crescimento do produto principal, levou à criação de muitos subprojetos e ramificações de interesse para desenvolvedores.

Introdução

MySQL é um dos programas de software livre mais populares da história. É o backbone de banco de dados de milhares de websites e pode-se dizer que detém o crédito (junto com Linux®) pelo crescimento explosivo da Internet nos últimos 10 anos.

Então, se o MySQL é tão importante, por que está aumentando o número de ramificações de alto perfil do produto MySQL principal? Como MySQL é software livre e gratuito, desenvolvedores sempre puderam pegar o código, modificá-lo conforme a necessidade e distribuir por conta própria. Por muito tempo, não havia nenhuma ramificação do MySQL em que um desenvolvedor confiasse em seu próprio ambiente de produção. No entanto, isso está mudando rapidamente. Várias ramificações estão recebendo muita atenção.

Este artigo irá discutir três ramificações populares do MySQL que estão atraindo atenção: Drizzle, MariaDB e Percona Server, incluindo o mecanismo XtraDB. Este artigo irá discutir brevemente os motivos para cada ramificação e suas metas e se o seu uso em seu ambiente de produção. Quando terminar de ler este artigo, você deve e star apto a responder à pergunta “Esses produtos de ramificação do MySQL são uma boa solução para o meu ambiente?”.

Por que ramificar?

Por que o MySQL precisa ser ramificado? Essa é uma pergunta legítima. Milhares de websites dependem dele e parece ser uma solução boa para muitas pessoas. No entanto, como acontece com frequência, o que é bom para muitas pessoas não é bom para todas as pessoas. Alguns desenvolvedores são incentivados a melhorar as coisas para suas próprias necessidades. O que poderia ser melhor do que transformar uma solução ótima numa solução perfeita?

Vamos examinar em melhores detalhes o que essas ramificações queriam mudar. Algumas ramificações acharam que o MySQL estava se tornando muito inchado e estava oferecendo muitos recursos que nunca iam interessar aos usuários, sacrificando simplicidade e desempenho. Se as pessoas estavam perfeitamente felizes com o MySQL 4, simplificado, por que deveriam lidar com a complexidade que foi incluída no MySQL 5? Para essa ramificação, uma ramificação do MySQL seria mais simples e mais rápida — oferecer menos recursos, mas torná-los extremamente rápidos, tendo em mente um público alto, nesse caso websites de alta disponibilidade.

Para outras ramificações, MySQL não estava oferecendo novos recursos suficientes ou os estava incluindo muito devagar. Eles talvez achassem que o MySQL não estava acompanhando seus mercados alvos de websites de alta disponibilidade executando em processadores com vários núcleos com muita RAM. Como sabem as pessoas familiarizadas com MySQL, ele oferece dois diferentes mecanismos de armazenamento — MyISAM e InnoDB. Essa ramificação achava que nenhum dos dois mecanismos de armazenamento oferecia exatamente o que eles queriam, por isso criaram um novo mecanismo perfeitamente adequado para seus objetivos.

Além disso, algumas ramificações têm como objetivo ser uma substituição de “entrada” (“drop in”) para o MySQL, na qual é possível simplesmente entrar na ramificação e não precisar escrever uma linha de código. A ramificação usa o mesmo código e interfaces que o MySQL, o que torna a transição o mais fácil possível. Outra ramificação afirma não ser compatível com MySQL e exige alterações no código. Cada ramificação também é muito diferente no nível de maturidade, com algumas afirmando estar prontas para produção, e outras afirmam estar longe desse objetivo no momento.

Por fim, há incerteza sobre como será o destino do MySQL com a Oracle. A Oracle comprou a Sun, que comprou MySQL, e agora a Oracle controla o produto MySQL, e lidera o desenvolvimento da comunidade na produção de novos produtos concluídos. Como a Oracle já tem um banco de dados comercial, há a preocupação de que a empresa pode não colocar recursos suficientes no MySQL para mantê-lo na ponta. Portanto, muitas ramificações também são resultado do medo subjacente de que o MySQL, o banco de dados grátis e de software livre líder, pode receber menos recursos, ciclos de release mais lentos e suporte mais caro.

XtraDB

XtraDB não é um produto independente, mas ainda é considerado uma ramificação de MySQL. XtraDB é, na verdade, um mecanismo de armazenamento para bancos de dados baseados em MySQL. Seria considerado um mecanismo de armazenamento adicional além do padrão MyISAM e InnoDB que já são parte do MySQL. MySQL 4 e 5 é instalado com cada tabela usando o mecanismo de armazenamento padrão MyISAM. InnoDB também é uma opção relativamente nova para mecanismo de armazenamento, e administradores e desenvolvedores de banco de dados podem escolher os tipos de mecanismo por tabela quando configuram o banco de dados. A principal diferença entre esses dois mecanismos de armazenamento é que MyISAM não oferece suporte transacional, mas InnoDB oferece. Outras diferenças são pequenas diferenças de desempenho, com InnoDB oferecendo pequenas melhorias de desempenho em relação a MyISAM, e mais confiabilidade e segurança ao lidar com perda de dados em potencial. Como InnoDB parece ser o mecanismo de armazenamento mais adequado para melhorias futuras, MySQL alterou o mecanismo padrão para InnoDB em vez de MyISAM a partir do release 5.5.

Construindo sobre essas vantagens, o mecanismo de armazenamento InnoDB foi ramificado em um novo mecanismo chamado XtraDB. Qual é a idade desse mecanismo de armazenamento? Ele foi lançado pela primeira vez há menos de 3 anos pela Percona. Portanto, é relativamente nova. Foi projetado especificamente para lidar com websites de alta disponibilidade modernos executando em servidores modernos. Foi projetado para executar em servidores com uma dúzia ou mais de núcleos e muita RAM (32 GB e mais). Esses são o tipo de servidores que qualquer empresa pode comprar de uma empresa de gerenciamento de servidores, e, portanto, um banco de dados deve ser projetado para aproveitá-los ao máximo.

A ramificação XtraDB tinha outro objetivo — ser uma substituição simples de entrada para o mecanismo de armazenamento InnoDB, de modo que usuários poderiam simplesmente alternar seu mecanismo de armazenamento sem ter que alterar o código do aplicativo subjacente. XtraDB tinha que ter compatibilidade retroativa com o InnoDB, além de fornecer todos os novos recursos e melhorias que eles queriam incluir. Eles atingiram esse objetivo.

Qual é a velocidade do XtraDB? Um teste de desempenho que eu encontrei diz que ele oferece 2.7x mais transações por minuto que o mecanismo InnoDB integrado no MySQL 5.1 (consulte Recursos). Certamente não é algo que pode ser ignorado, especialmente considerando que pode ser usado imediatamente.

Percona

XtraDB oferece ótimas melhorias sobre mecanismos de armazenamento MySQL integrados, mas não é um produto independente, e não é algo que se possa colocar em uma instalação MySQL existente. Portanto, se você quiser usar esse novo mecanismo de armazenamento, é preciso usar um produto que o ofereça.

Percona Server é esse produto, lançado pela Percona, empresa líder em consultoria de MySQL. É um produto de banco de dados independente que oferece aos usuários a capacidade de retirar sua instalação do MySQL e colocar o produto Percona Server, e assim obter a vantagem do mecanismo de armazenamento XtraDB. Afirma ser totalmente compatível com MySQL, portanto em teoria nenhum código precisaria ser alterado no software. Isso é, certamente, uma enorme vantagem. É ótimo para controle de qualidade quando você está procurando por uma melhoria de desempenho rápida. Portanto, um bom motivo para considerar Percona Server é aproveitar o mecanismo XtraDB com o menor número de alterações possível no código principal.

Além disso, eles são os autores originais do mecanismo de armazenamento XtraDB. A Percona lançou o código como software livre, de modo que ele pode ser encontrado em outros produtos, mas os criadores originais do mecanismo são as mesmas pessoas que criaram este produto. Usem essas informações como quiser.

Aqui estão as afirmações feitas para o Percona Server, retiradas do website deles:

  • Escalabilidade: lida com mais transações; faz ajuste de escala em servidores eficientes
  • Desempenho: Percona Server com XtraDB é extremamente rápido
  • Confiabilidade: resiliência a corrupção, replicação com segurança contra quebra
  • Gerenciamento: backup on-line, importação/exportação de tabela on-line
  • Diagnóstico: perfil e instrumentação avançados
  • Flexibilidade: tamanho de página variável, gerenciamento de buffer pool melhorado

A afirmação final da equipe do Percona é que o produto é o “mais próximo dos releases oficiais MySQL Enterprise da Oracle”, assim se diferenciando de outras ramificações que alteraram o código MySQL principal subjacente. Um ponto negativo do Percona Server é que eles gerenciam o código por si mesmos e não aceitam contribuições de desenvolvedores externos sem revisá-la antes, o que garante que eles controlem os recursos colocados no produto.

MariaDB

Outro produto que oferece o mecanismo de armazenamento XtraDB é o produto MariaDB. É muito semelhante ao produto Percona, mas oferece mais alterações no código subjacente para tentar obter ainda mais melhorias de desempenho em relação ao MySQL padrão. Utiliza o mecanismo XtraDB diretamente da Percona, portanto não á diferenças subjacentes nos mecanismos de armazenamento que cada um emprega, já que usam exatamente o mesmo.

Além disso, MariaDB oferece os mecanismos de armazenamento padrão oferecidos pelo MySQL, MyISAM e InnoDB. Portanto, na prática, pode ser considerado um superconjunto de MySQL, oferecendo tudo que o MySQL oferece e mais. Também afirma ser uma substituição de entrada para o MySQL, portanto pode ser instalado com o conhecimento de que não serão necessárias alterações no código subjacente ao passar o MySQL para o MariaDB.

Por fim, e talvez o mais importante, o criador chefe do MariaDB é Monty Widenius, o criador original do MySQL. Monty formou uma empresa para gerenciar o desenvolvimento do MariaDB, chamada Monty Program, que contrata desenvolvedores para criar e melhorar o produto MariaDB. Isso pode ser algo bom e ruim: é bom porque eles lideram os recursos e correções de erros no Maria, mas pode causar problemas porque a empresa não está focada em receita, mas sim em produto. Empresas que não geram receita não duram para sempre.

Drizzle

O último produto que iremos examinar é o Drizzle. Ao contrário dos outros dois produtos finalizados que examinamos, o Drizzle apresenta grande diferença em relação ao MySQL e até mesmo afirmam que o produto não é uma substituição simples para o MySQL. Eles estão tentando fazer mais mudanças importantes no MySQL e tem como objetivo fornecer uma ótima solução para o problema da alta disponibilidade, mesmo que isso signifique alterar aspectos do MySQL com os quais estamos acostumados.

No FAQ da empresa, a leitura das questões reforça os objetivos subjacentes. Eles não estavam satisfeitos com as alterações feitas no núcleo do MySQL após o release 4.1, afirmando que muitos desenvolvedores não queriam aquela sobrecarga adicional. Eles admitem que seu produto não é sequer um banco de dados de relação compatível com SQL. Isso é realmente diferente do MySQL.

Então, com uma mudança tão drástica em relação ao MySQL familiar, por que deveríamos considerar esse produto? Exatamente por esses motivos — é uma grande reescrita dos mecanismos do MySQL, com os recursos que foram considerados não ideais removidos, e com grande parte do código sendo reescrita para ser otimizada, chegando a ponto de trocarem C por C++ no código. E não acaba aí: esse produto tem um mercado alvo específico em mente com seu design — servidores com vários núcleos e muita RAM, máquinas de 64 bits executando Linux, servidores usados em computação em nuvem, servidores hospedando websites, servidores obtendo dezenas de milhares de ocorrências por minuto. É um mercado bem específico. É específico demais? Lembre-se do quanto esse tipo de empresa gasta com seus bancos de dados atualmente — se ela pode instalar Drizzle em vez de MySQL e cortar os custos com servidor pela metade, isso é muito dinheiro!

Então todos deveriam estar usando Drizzle, certo? Espere, pois, como eles destacam repetidamente, não é compatível com MySQL. Portanto, se você tem uma plataforma MySQL existente, haveria muitas alterações a serem feitas no código para fazer com que ele funcione corretamente no seu ambiente.

Embora exija mais trabalho para executar e não pareça ser tão rápido e fácil de usar como Percona ou MariaDB, eu incluo Drizzle porque, embora ele possa não ser sua escolha hoje, em alguns anos será provavelmente a escolha de algumas pessoas. Como o objetivo deste artigo é informar sobre as ferramentas que você usará no futuro, essa é uma boa oportunidade de mostrar esse produto. Muitos especialistas de DB líderes acham que o Drizzle será a escolha de instalações de alta disponibilidade em cinco anos.

Drizzle é 100% software livre e recebe contribuições abertamente de desenvolvedores. Não há uma empresa subjacente financiando o desenvolvimento, como no MariaDB, e não é fechado para contribuições de fora, como Percona. Está em uma boa posição para crescimento e novos recursos, que ele pode precisar, dado seu escopo de reescrever grande parte do MySQL.

Gráfico de comparação

Aqui está um resumo dos três produtos de ramificação MySQL mencionados neste artigo.

Produto Preços Objetivo Recurso Principal Pronto para Produção?
Percona Server Grátis Fornece um wrapper para mecanismo de armazenamento XtraDB e ferramentas de análise adicionais XtraDB Sim
MariaDB Grátis Estendeu MySQL para incluir XtraDB e outras melhorias de desempenho XtraDB Sim
Drizzle Grátis Oferece grandes melhorias de escalabilidade e desempenho em relação ao MySQL Alta disponibilidade Sim

Conclusão

Este artigo discutiu três novas ramificações do produto MySQL que intencionam resolver alguns problemas identificados com o MySQL. Os três são grátis e são produtos de software livre. É preciso pesar as vantagens e desvantagens de usá-los em relação ao que o MySQL já oferece. Eu acredito que, para quase todos que leem este artigo, MySQL será ainda a escolha preferencial para suas necessidades de bancos de dados. Eu duvido que muitos leitores deste artigo sejam proprietários de websites que recebem 1.000.000 de ocorrências por hora. Quero destacar isso novamente — MySQL ainda é um produto incrível que é um banco de dados perfeitamente adequado para a maioria dos casos de uso.

No entanto, para vocês que acham que seu site requer mais alta disponibilidade, escalabilidade e desempenho do que o MySQL pode oferecer atualmente, um desses três produtos pode ser a solução que vocês procuram. No futuro, se você acha que seu site irá se tornar uma ideia de um bilhão de dólares, deve-se considerar começar com um desses três produtos e assim resolver esses tipos de problemas antes mesmo que eles comecem.

Por fim, o motivo principal dessas ramificações do MySQL é alterar alguns recursos subjacentes do MySQL, sendo que os autores acharam que não podiam esperar que o MySQL fizesse isso. Além disso, o espectro da Oracle ronda sobre o futuro do MySQL, e muitos desenvolvedores, incluindo o desenvolvedor original do MySQL, estão preocupados sobre o futuro do produto e se a Oracle irá mostrar a devoção ao produto que um banco de dados de ponta exige. Na minha opinião, todas essas preocupações são válidas, e, por esse motivo, você deve manter esses três produtos em mente enquanto caminhamos para o futuro.

Recursos

Aprender

Obter produtos e tecnologias

  • Como você está interessado no desenvolvimento de banco de dados, talvez queira experimentar o produto gratuito IBM DB2 Express-C.
  • Experimente outro software IBM sem custo. Faça o download de uma versão de avaliação, faça login em uma versão de avaliação on-line, trabalhe com o produto em um ambiente de simulação ou acesse-o por meio da nuvem. Escolha dentre mais de 100 versões de avaliação de produtos IBM.

Fonte: Michael Abernethy/IBM

MySQL 5.5.18 traz correções para problemas de replicação

A Oracle disponibilizou o MySQL 5.5.18, a última das atualizações regulares para a versão de produção do banco de dados open source. Na atualização, a Oracle tem marcado uma série de situações inseguras em replicação “statement-based”.

As declarações questionadas fazem referência ao resultado de uma instrução “select”, na qual a ordem não pode ser confiada. Sendo assim, a Oracle aconselha os utilizadores de “logging statement based” a consultar a documentação para obter mais orientações. O problema de replicação em que o master (mestre) podia enviar eventos danificados para os slaves (escravos) relacionados ao disco e ao log binário também foi corrigido.

Outras mudanças incluem melhorias para a biblioteca libedit junto com MySQL, remoção de alocação de memória desnecessária e liberação ao abrir tabelas, além de correções para falhas relacionadas com ARCHIVE e tabelas FEDERATED, e uma possível corrupção com o comando OPTIMIZE TABLE ao usar MyISAM.

Os desenvolvedores também fizeram o possível, em relação à utilização de RPM, para substituir qualquer versão instalada do MySQL com outra da mesma versão da família, por exemplo, quando houver a atualização da versão GPL para a versão comercial.

Todos os detalhes sobre essas mudanças estão disponíveis aqui, e o MySQL 5.5.18 pode ser baixado neste link.

Com informações de Under-Linux

Fonte: IMasters

Lançado Sqlsus 0.7

Sqlsus é uma ferramenta open source de SQL injection (MySQL) e takeover, escrita em Perl. Através de uma interface de linha de comando, ela possibilita recuperar a estrutura de um banco de dados, injetando suas próprias consultas SQL (mesmo as mais complexos), realizar download de arquivos do servidor Web, rastrear o site para diretórios graváveis, fazer upload, controlar um backdoor, entre outras funcionalidades.

Sqlsus concentra-se na velocidade e eficiência, otimizando o space injection disponível. Além disso, ele oferece uma interface fácil de usar, com muitas características interessantes e peculiares. Na versão 0.7, Sqlsus recebe a adição de uma progress bar para o modo “inband”, que determina o número de linhas a ser devolvido antes de consultá-las.

Aos interessados em fazer download e testar o utilitário, a sua nova versão está disponível a partir do sistema de hospedagens do Source Forge.

Post original em http://sqlsus.sourceforge.net/download.html

Fonte: Under-Linux

WebMatrix 2.0 – o que ele traz de melhor e porque você deveria conhecê-lo!

Já falamos aqui das novidades do WebMatrix em 2011, e também já mostramos como ele pode ajudar para que você faça a web de forma simples, rápida e muito eficiente. Mas você sabe como isso realmente afeta a sua vida, o seu trabalho?

O WebMatrix é um IDE (Integrated Development Enviroment – Ambiente de desenvolvimento integrado) que utiliza o Web Platform Installer para instalar e configurar automaticamente os componentes de software necessários para desenvolver uma determinada aplicação. Isso quer dizer, simplesmente, que ele vai te ajudar a “instalar” tudo aquilo que você precisa para fazer um site, como um Blog WordPress, sem precisar conhecer nada de programação. Hoje, 2/3 da web é baseada em web applications prontas, testadas e aprovadas. Não é necessário mais arriscar.

Como tudo, o WebMatrix está em constante evolução. E a versão 2.0 ganhou alguns diferenciais importantes, que vão facilitar a sua vida, deixando-o independente dentro da web, permitindo que você possa criar o seu site, mesmo que você não seja um desenvolvedor ou que esteja começando nessa área.

Uma das novidades são os novos templates disponíveis, que facilitam a criação de websites, e aplicativos web. Não bastassem os templates, o WebMatrix possui um novo sistema de code complete que auxilia o usuário a escolher as cores utilizadas no CSS graficamente.

Outro ponto que essa versão trabalhou foi o incentivo aos usuários para que eles entendam as tecnologias as quais a ferramenta dá suporte. Sendo assim, eles passaram a disponibilizar diversos tutoriais, com exemplos bem detalhados, para que o usuário possa entender a codificação à medida que ela ocorre.

Ainda seguindo a linha de pensamento “fazer a web de forma mais simples”, o WebMatrix implementou nessa versão os Helpers, que são blocos de códigos que podem ser utilizados na sua aplicação WebMatrix como atalhos simplificados para integração com ferramentas como redes sociais, por exemplo. A galeria de Helpers é aberta e você já encontrará facilmente a integração com Facebook, Twitter, Foursquare, PayPal, dentre outros.

Outra novidade é o relatório WebMatrix SEO (Search Engine Optimization), que é uma ferramenta que analisa o seu site e dá sugestões, quando necessário, para corrigir o que está errado. Com esta ferramenta você pode melhorar o posicionamento do seu site para os motores de busca.

Você já tem um site publicado e ficou arrependido de não ter utilizado o WebMatrix? Não precisa. Você também pode conectar a sites já publicados, utilizando o WebMatrix, alterar e fazer o upload diferente.

O WebMatrix ainda oferece um gerenciador visual de banco de dados com uma interface simples e amigável para Sql Server 2005/2008 e MySQL 5.x/6.x, mas se você não possui servidor de banco de dados não se preocupe! O WebMatrix possui um pequeno servidor de banco de dados incorporado o Sql Server Compact e ainda utiliza o Web Plataform Installer para instalar e configurar automaticamente o MySQL caso seja necessário.

Fonte: IMasters

WordPress 3.3 ganha versão beta 1

Ryan Boren, chefe de desenvolvimento do WordPress, anunciou o primeiro beta da versão 3.3 do CMS. Entre as melhorias estão uma novo uploader de mídia em HTML5.

Nas versões anteriores o uploader usou um diálogo de seleção de arquivos padrão para a selecionar arquivos a serem enviados, enquanto que a versão anterior à 3.3 utiliza Plupload, um manipulador de upload open source, que inclui funcionalidades de arrastar e soltar. O redimensionamento da imagem está disponível dentro do navegador. O Plupload tem métodos de reserva, incluindo Flash e envio padrão para navegadores que não suportam HTML5.

Muitas mudanças têm sido realizadas pelos administradores. O backend agora suporta “admin pointers”, pequenos textos exibidos quando o usuários seleciona uma parte da interface; eles trazem informações sobre as novas features do WP.

Os admin pointers podem ser configurados não só pelos desenvolvedores, mas também pelos designers que irão, no futuro, ser capaz de implementá-los para explicar as opções de configuração personalizada dos tema.

Além disso, houve melhorias na barra de menu administrativo, além de um novo tutorial para iniciantes e uma área de dashboard adaptável, que automaticamente redimensiona para dispositivos móveis.

A previsão para o lançamento do WordPress 3.3 é o final de novembro. A versão beta já está disponível para download e pode ser instalada ou testada usando o plugin para teste do WordPress Beta. É necessário PHP 5.2.4 e MySQL 5.0, ou versões mais atualizadas.

Boren afirmou que os desenvolvedores estão “fazendo quase que diariamente uma checagem nos bugs no #wordpress-dev para reduzir a contagem de ticket”, e solicita que os usuários que descobrirem bugs os informem no fórum WordPress alpha/beta ou na lista de discussão wp-testers.

Com informações de The H

Fonte: IMasters