Dica: Migrando MySQL para PostgreSQL
Migrando MySQL para PostgreSQL
Você pode já ter lido vários artigos sobre esse assunto na web, mas provavelmente conseguiu apenas partes da informação necessária. É hora de colocar tudo junto e na prática.
Você tem um projeto/sistema rodando no MySQL e de repente você descobre que você precisa migrar para PostgreSQL. E você se depara com um SQL diferente para cada plataforma, o MySQL trabalha com SQL e o PostgreSQL trabalha com PL/SQL, mas você não tem tempo para reescrever o código do zero e, logicamente, se você tiver tempo de reestruturar o seu projeto para PostgreSQL, o seu Data Base vai ficar mais organizado e, como um bom Data Base deve ser com relacionamento entre tabelas, trigger, functions e etc.
Na verdade, pode haver boas razões para migrar um Data Base de MySQL para PostgreSQL:
- Você podera vender o seu produto com total tranquilidade (PostgreSQL é licenciada BSD, o diferente de MySQL)
- Você pode encontrar artigos “Migrando MySQL para PostgreSQL” na web, mas você não vai encontrar nenhuma “Migrando PostgreSQL para MySQL”
- PostgreSQL não pode ser apenas mais um péssimo banco de dados se o Skype, Cisco, Juniper, IMDb, Pandora ou NOVA TV decidiram confiar nele, além de a Sun Microsystems tê-lo tornado como base de dados de escolha (o que é extremamente hilario, já que em janeiro de 2008 ela comprou o MySQL)
No PostgreSQL você ainda pode sentir um pouco como se senti uma pessoa com segurança particular. Existem alguns grandes projetos como o Asterisk, Horde ou DBMail que já reconheceram suas qualidades e que, embora o MySQL tenha sido sua primeira escolha de Banco de Dados, eles estão demonstrando grande esforço para fazer tudo funcionar corretamente.
Convertendo Base de Dados MySQL para PostgreSQL
Primeiro vamos fazer Backup de nossa Data Base MySQL com o software mysqldump do próprio MySQL:
"mysqldump --compatible=postgresql bancodedados > bkp-bancodedados.sql"Convertendo caracteres para o SQL ficar funcional no PostgreSQL:
"sed "s/\\\'/\'\'/g" bkp-bancodedados.sql"
* Este processo vai demorar muito tempo porque o software "sed" varrerá
todo o arquivo para fazer a conversãoColocando para funcionar: importando para o PostgreSQL
"psql -h server -d databasename -U username -W < bkp-bancodedados.sql"Com isso você migrou sua estrutura de Dados de MySQL para PostgreSQL.
Fonte: iMasters
Os maiores bancos de dados do mundo
Quem trabalha com banco de dados ja deve ter tido a curiosidade de saber qual o maior banco de dados do mundo, para ter noção do tamanho, da grandeza da administração e do tempo que deve executar uma instrução SQL, rebuild de índice e tudo mais.
Entao, achei alguns materiais na internet que falam justamente desses bancos de dados, que podem ser de diferentes fabricantes, tanto Oracle, IBM, Microsoft, PostGreSQL e etc. O mais interessante são os números ou métricas que chegaram nessas conclusões e relatam um pouco da infra-estrutura utilizada para cada ambiente de banco de dados.
È importante também é saber que esses artigos e documentos não são de fontes oficiais das empresas ou de alguma organização responsável e séria sobre esse específico tipo de assunto. Como hoje em dia temos o TPC.ORG, que corresponde aos benchmarks sobre Performance vs Custo, esses documentos são meramente para matarmos algumas curiosidades, mas nada confirmado pelas empresas ou estabelecimentos que utilizam esses bancos de dados.
O documento que está abaixo relata o TOP 10 dos maiores bancos de dados do Mundo, e o mais interessante do documento são os números que os tornam gigantescos. O documento pode ser lido aqui: Top Largest Databases in the World We all collected
Porém, se continuar navegando um pouco mais na internet, irá se deparar com um artigo da ComputerWorld falando que o maior banco de dados do mundo é do Yahoo!, que possui um banco de dados na casa dos 2 PB (PetaBytes). Veja:
Yahoo! The database 2 PetaBytes.
Mas, como é um artigo do ano de 2008, talvez esses números já estejam bem maiores. E sou da opinião que devem existir bancos de dados bem maiores dos que os divulgados e analisados. Um exemplo para ampliar a curiosidade são as bases de dados de organizações como:
* Organizações que cuidam do clima (Cálculos e Imagens);
* Empresas que trabalham com tecnologia GIS (Mapeamento – GPS);
* Empresas de Media Center.
E por último o DETRAN-SP, se o estado tem a terceira maior frota de automóveis do mundo e a cidade tem radar para tudo que é lado, imagina a quantidade de transações diárias (com imagem da placa do seu carro) que é gerada por hora para cada multa? Fico curioso para saber o tamanho dessa base.
Fonte: iMasters
Google lança banco de dados para competir com Oracle, IBM e Microsoft
O Google lançou silenciosamente um novo banco de dados online chamado Fusion Tables, com o objetivo de revolucionar o gerenciamento de dados.
A idéia é driblar as limitações dos bancos de dados tradicionais e simplificar as operações de relacionamento de informações. O Google afirmou que, com a implementação em cloud computing, simplificará também a possibilidade de colaboração em grupos de dados.
“Sem um jeito fácil de oferecer acesso a todos os colaboradores ao mesmo servidor, os dados são copiados e enviados por e-mail e FTP, resultando em várias versões que saem de sintonia rapidamente”, diz o anúncio do Google.
O Fusion Tables também oferece uma tecnologia de espaço de dados, conceito que existe desde os anos 90 e o Google, percebendo seu potencial, o desenvolve desde a compra da Transformic, em 2005, que é uma pioneira da tecnologia.
O esquema de ‘espaço de dados’ tenta resolver o problema de vários tipos e formatos de dados nas empresas, que gastam muito em dinheiro e esforços para torná-los uniformes, com o objetivo de armazená-los e analisá-los em bases de dados convencionais.
Os ‘espaços de dados’ preveem um sistema que cria um índice para oferecer acesso a dados de vários tipos e formatos, resolvendo o problema que o Google chama de “Torre de Babel”.
A tecnologia permite que o Google inclua, nas tabelas bidimensionais tradicionais de base de dados, uma terceira coordenada com elementos como reviews de produtos, posts e mensagens do Twitter, além de uma quarta ‘dimensão’ de atualizações em tempo real.
“Agora temos um espaço com quatro dimensões onde podemos incluir novas perguntas para criar novos produtos e oportunidades de marketing”, diz o anúncio. “Se você é a IBM, a Microsoft e Oracle, seu pior pesadelo está vivo. O Google irá criar espaços de dados automaticamente e implementar novos tipos de pesquisas.”
O Fusion Tables é uma versão prévia do produto, e carrega a marca “Labs” de produto experimental do Google.
Conectando C# ao MySQL
Quem está habituado a programar C# normalmente utiliza SQL Server como banco de dados, uma vez que ela está integrada no Visual Studio e, por isso mesmo, existe grande facilidade em trabalhar com as duas ferramentas.
Por vezes existem projetos em que se torna conveniente (por várias razões) utilizar outro tipo de base de dados. Seja que banco de dados for, a sua integração é sempre diferente do SQL Server.
Neste caso vou mostrar como fazer a integração entre o C# e o MySQL.
Supondo que já existe uma instalação do MySQL na máquina, precisamos instalar um intermediário entre o C# e a base de dados. Neste caso necessitamos instalar o MySQL Connector NET.
A versão 5.2 já tem suporte ao Visual Studio 2008, mas eu vou utilizar a última versão (6.0).
Instalamos o Connector Net 6.0.
Devemos já ter uma base de dados com uma tabela (users por exemplo), em que os campos da tabela são: id, nome, email.
Como exemplo criamos um projecto Windows Forms Application.
Antes de mais nada, devemos fazer uma referência à classe que vai ligar o C# ao MySQL. Para isso vamos ao painel Solution Explorer, na raiz do projeto, clicamos com o lado direito do mouse e selecionamos Add Reference.
Na primeira divisória (.NET) selecionamos a referência MySQL.Data e damos OK.
Não esquecer: incluir no início do código as classes:
using System.Data;
using MySql.Data.MySqlClient;
Sem adicionar a referência à MySQL.Data, a classe MySql.Data.MySqlClient não será reconhecida.
Para exemplificar fazemos um formulário de inserção de dados (nome e e-mail) na base de dados.
No form colocamos duas caixas de texto, uma para o nome (txtNome) e outra para o e-mail (txtMail) e um botão que terá a ação de inserir os dados na base de dados.
Vamos então definir, em primeiro lugar, o dataset e a string de conexão à base de dados.
private MySqlConnection bdConn; //MySQL
private MySqlDataAdapter bdAdapter;
private DataSet bdDataSet; //MySQLNa ação do botão:
//Definição do dataset
bdDataSet = new DataSet();
//Define string de conexão
bdConn = new MySqlConnection("Persist Security Info=False;server=localhost;database=rfidapp;uid=root;server=localhost;database=rfidapp;uid=root;pwd=''");Neste caso a base de dados não tem password.
//Abre conecção
try{
bdConn.Open();
}
catch{
MessageBox.Show("Impossível estabelecer conexão");
}
//Verifica se a conexão está aberta
if (bdConn.State == ConnectionState.Open)
{
//Se estiver aberta insere os dados na BD
MySqlCommand commS = new MySqlCommand("INSERT INTO regists VALUES('',\\'" + txtNome + "\\',\\'" + txtMail + "\\')", bdConn);
commS.BeginExecuteNonQuery();
}Tome atenção na sintaxe do SQL para o MySQL (INSERT) que é um pouco diferente do C#/SQL Server.
Neste momento o formulário deverá inserir dados no BD.
Fonte: Imasters
Liferay Portal – Configuração da ligação a uma base de dados MySQL
1. Criação da Base de Dados MySQL
Criem a base de dados com o nome lportal.
Poderão fazer isto utilizando o MySQL Administrator (a ferramenta de administração do MySQL) ou usando a seguinte linha de comando:
mysqladmin –default-character-set=utf8 create lportal
2. Configuração do acesso à base de dados com o eclipse
Abram o Data Source Explorer do eclipse (Window -> Show view -> Data Source Explorer).
Selecionem o ícone ‘New Connection Profile’ ou usem o botão direito do mouse sobre ‘Databases’ e depois selecionem ‘New’.
Na janela ‘New Connection Profile’ selecionem o tipo SQL Model-JDBC Connection.
No quadro seguinte, indiquem um nome para o perfil (ex: ‘Liferay – Mysql’).
No último quadro, usem o botão de procura (‘?’) na lista “Select a browser”.
Adicionem uma nova definição:
- Localizem o template para bases de dados MySQL na árvore (Database -> MySQL -> 5.0 -> MySQL JDBC Driver).
- Alterem as definições do driver:- Alterem o nome para ‘Liferay MySQL Driver’;
- Removam o driver ‘default’ e adicionem um novo Jar correspondente ao arquivo $WORKSPACE/ext/lib/development/mysql.jar ($WORKSPACE corresponde à localização da pasta do seu workspace no sistema de arquivos);
- Configurem o valor das propriedades de acesso (username, password, etc?) tendo em atenção que o valor do ‘Database Name’ e, por consequência, o final da linha do ‘Connection URL’ deverá ser ‘lportal’.
- Confirmem as alterações e selecionem agora este driver nas definições do driver (Database -> MySQL -> 5.0 -> Liferay MySQL Driver).
Voltem de novo à janela de criação do perfil e validem que todas as informações estão de acordo com a sua configuração (podem testar a ligação a partir desta janela).
3. Criação do modelo de dados
Editem o arquivo create-mysql.sql na pasta /sql/create do projecto ‘ext’. Caso não tenham memória para desperdiçar (é o meu caso), respondam afirmativamente quando o eclipse perguntar se pretendem desligar a validação de sintaxe do arquivo.
No topo da janela de edição do ficheiro está a configuração do ‘Connection profile’. Selecionem o tipo Generic JDBC_1.x, o driver ‘Liferay – Mysql’ e a base de dados lportal.
Nota: caso o status não seja ‘Connected’ , vocês não vão conseguir ver o nome da base de dados.
Neste caso devem acessar o Data Source Explorer ( Window -> Show View -> Data Source Explorer), selecionar a Database ‘Liferay – MySQL’ e fazer connect (botão direito do mouse)
Comentem as três primeiras linhas do ficheiro, uma vez que a base de dados já foi criada
- drop database if exists lportal;
- create database lportal character set utf8;
- use lportal;
Gravem e executem o sql (ctrl+alt+X ou Execute All no menu contextual).
4. Configuração do datasource no tomcat
Editem o arquivo Root.xml localizado na pasta servers/tomcat/conf/Catalina/localhost do projeto ‘ext’.
Comentem o datasource do Hypersonic e descomentem o datasource do MySQL.
Preencham os atributos username e password e, caso não estejam usando os valores default do MySQL, editem também o valor do atributo url, de acordo com a sua configuração.
Gravem as alterações.
5. Deploy da configuração para o servidor
Copiem o arquivo Root.xml para a pasta conf/Catalina/localhost do tomcat.
Copiem e o arquivo mysql.jar para para a pasta lib/ext do tomcat.
Fonte: Imasters
Cluster no MySQL – Parte 2
Antes de entrar nos detalhes técnicos, recomendo a todos que estiverem lendo esta coluna que confiram a primeira parte da configuração do cluster, onde mostro qual é a arquitetura da solução e discuto alguns aspectos de um cluster MySQL. A primeira parte pode ser encontrada aqui.
A partir do diagrama mostrado no artigo anterior precisamos fazer uma instalação nova do MySQL no servidor 192.168.1.35. O servidor 192.168.1.15 conterá as ferramentas administrativas do cluster e não precisa do MySQL instalado. Contudo, as ferramentas administrativas do cluster são distribuídas junto com os arquivos do MySQL.
A instalação do MySQL no servidor 192.168.1.35 deve ser feita da mesma maneira que o servidor já existente, isto é, o MySQL no servidor 192.168.1.35 deve conter todas as opções e configurações do servidor 192.168.25, pois a idéia é que o cluster funcione de forma transparente para a aplicação. Além disso, também é preciso transferir os usuários, objetos e permissões, pois o banco de dados será criado posteriormente. Em resumo, é preciso primeiro duplicar o ambiente do servidor 192.168.1.25 para o servidor 192.168.1.35, tomando cuidado com as configurações.
Uma vez que os dois servidores MySQL estiverem configurados e sendo executados nos servidores 192.168.1.25 e 192.168.1.35 podemos começar a configuração do cluster. O primeiro passo é configurar o serviço que fará a administração do cluster chamado mgmd (management deamon) no servidor 192.168.1.15. Antes de iniciar este serviço é preciso cadastrar os endereços I.P. dos nós do cluster no arquivo de configurações chamado config.ini, que está no mesmo diretório dos binários do mysql.
O arquivo config.ini possui várias sessões e chaves de configuração. De acordo com a arquitetura do exemplo, precisamos indicar neste arquivo que o servidor 192.168.1.15 conterá as ferramentas administrativas do cluster e que os servidores 192.168.1.25 e 192.168.1.35 serão os nós do cluster. Fazemos isso modificando a chave HostName da sessão [NDB_MGMD] de modo a colocar o endereço do servidor que conterá as ferramentas administrativas. Para cada nó do cluster devemos colocar o seu endereço na chave HostName da sua respectiva sessão [NDBD]. A Figura 1 mostra como ficará o arquivo config.ini do servidor que contém as ferramentas administrativas do cluster após a modificação de seu conteúdo em um simples editor de texto. As mudanças na seção [NDB_MGMD] são destacadas pelo retângulo amarelo e as modificações nas duas seções [NDBD] são destacadas pelo retângulo branco.
Figura 1. Modificações no arquivo de configuração config.ini
Após acertar os endereços IP dos servidores no arquivo de configuração config.ini é preciso iniciar o serviço mgmd (management deamon). Antes de iniciá-lo é preciso ter certeza que os MySQL dos servidores indicados como nós do cluster não estão sendo executados. Para iniciar o serviço mgmd no servidor 192.168.1.15 basta executar o deamon pelo comando ndb_mgmd, como as últimas linhas da Figura 2 mostram. Para verificar se o serviço foi iniciado sem problemas podemos utilizar o seguinte comando que verifica os processos do servidor: ps -A | grep mgm.
Figura 2. Iniciando o servidor ndb_mgmd.
Após iniciar o serviço podemos nos conectar localmente ou remotamente na ferramenta de administração do cluster. Esta ferramenta chama-se Management Client e é executada pelo comando ndb_mgm. Após iniciar a ferramenta devemos enviar o comando SHOW para verificar o estado do cluster, como mostra a Figura 3.
Figura 3. Executando o Management Client do cluster MySQL.
A ferramenta Management Client é um console para a administração do cluster MySQL no Linux. Após a execução do comando SHOW ela mostra os nós que estão conectados ao cluster. Pode-se notar pela Figura 3 que o cluster colocou o id 2 para o servidor 192.168.1.25 e o id 3 para o servidor 192.168.1.35. A ferramenta também mostra que o id 1 corresponde ao servidor 192.168.1.5, pois ele contém o serviço de administração do cluster (ndb_mdmd). É possível modificar as configurações do cluster, inclusive adicionar ou remover nós, por meio de comandos enviados ao Management Client.
Agora que já configuramos o serviço de administração do cluster é preciso modificar as configurações em cada um dos nós. Estas configurações são armazenadas no arquivo de configuração do MySQL chamado my.cnf. Não devemos nos esquecer de parar o serviço do MySQL antes de alterar o arquivo my.cnf. No exemplo este arquivo estava localizado no diretório /etc/mysql, porém esta localização pode variar de acordo com a instalação do MySQL.
Para configurar um nó de modo que ele faça parte de um cluster MySQL é preciso alterar três chaves em duas sessões do arquivo my.cnf. As duas primeiras chaves são a ndbcluster e a ndb-connectstring, sendo que esta última deve receber o endereço 192.168.1.15, que é o servidor onde o serviço de administração do cluster está instalado. Por padrão, estas chaves estão comentadas com o símbolo cerquilha (#) e estão dentro da sessão [MYSQLD]. Basta retirar os comentários e colocar o valor o endereço IP 192.168.1.15, como mostrado na parte esquerda da Figura 4 e destacada pelo retângulo vermelho.
Também é preciso alterar a chave ndb-connectionstring da sessão [MYSQL_CLUSTER], que também está comentada por padrão e se encontra abaixo da sessão [MYSQLD] no arquivo my.cnf. Da mesma forma que a chave anterior, é preciso colocar o endereço do servidor que contém o serviço de administração do cluster na chave ndb-connectionstring da sessão [MYSQLD]. Esta chave é mostrada à direita na Figura 4 e destacada pelo retângulo preto.
Figura 4. Chaves que devem ser modificadas no arquivo my.cnf
Após a modificação das chaves no arquivo my.cnf é preciso iniciar o serviço do MySQL. No exemplo iniciei o serviço utilizando o comando mysqld_safe -user=mysql &. Além disso também é preciso iniciar o serviço ndbd nos nós do cluster, pois ele é o responsável por gerenciar o acesso aos arquivos com os dados compartilhados. Os comandos que iniciam os serviços mysql e ndbd são mostrados na Figura 5.
Figura 5. Iniciando os serviços MySQL e ndbd em um dos nós do cluster
Nota importante:
é preciso repetir os passos anteriores para cada nó do cluster. Ou seja, tanto para o servidor 192.168.1.25 como para o servidor 192.168.1.35 é preciso alterar o arquivo de configuração my.cnf e iniciar os serviços MySQL e ndbd.
A partir deste momento o cluster já está sendo executado. Podemos enviar o comando SHOW na interface console do Management Client do cluster e verificar que os dois nós já são considerados parte do cluster, como mostra a Figura 6.
Figura 6. Verificando os nós do cluster.
Apesar de o cluster já estar configurado, a partir desde momento os dois servidores MySQL ainda estão trabalhando de forma independente. Para que possamos usufruir das funcionalidades do cluster é preciso criar manualmente um banco de dados com o mesmo nome em cada servidor e, dentro deste banco de dados, criar tabelas que utilizem o engine de banco de dados NDBCLUSTER. Mas atenção: o banco de dados deve ser criado manualmente nos dois nós com o comando CREATE DATABASE, porém as tabelas precisam ser criadas apenas uma vez em qualquer um dos nós do cluster. A Figura 7 mostra a criação do banco de dados chamado CLUSTER e da tabela TB_ONE em um dos nós do cluster e utilizando os comandos CREATE DATABASE e CREATE TABLE, respectivamente.
Figura 7. Criando o banco de dados CLUSTER e a tabela TB_ONE.
Como a tabela TB_ONE foi criada utilizando o engine de banco de dados NDBCLUSTER todas as modificações nos dados realizadas em qualquer um dos nós será replicada automaticamente para os demais. Podemos fazer um teste simples incluindo uma linha na tabela TB_ONE em um dos nós e verificar que esta linha foi automaticamente enviada para a tabela TB_ONE do outro nó.
Com o cluster conseguimos montar uma solução que atende a requisitos de alta disponibilidade, pois caso um nó do cluster não esteja operacional isso não será um problema para a aplicação, uma vez que os outros nós funcionaram de forma independente. Quando o nó que apresentou um problema foi iniciado novamente o próprio serviço NDBD irá procurar as informações perdidas e tentará sincronizar os dados da tabela.
Um detalhe importante de ser lembrando é que com o cluster os usuários podem se conectar tanto no servidor 192.168.1.25 (ubuntu02) como no servidor 192.168.1.35 (ubuntu03). Mas se eles tentarem se conectar ao servidor que possui as ferramentas administrativas, cujo endereço é 192.168.1.5 (ubuntu01), eles não conseguiram se conectar. Por isso é recomendável utilizar o serviço MySQLProxy, explicado anteriormente aqui, de modo que as aplicações possam se conectar em apenas um servidor que conterá tanto o software de balanceamento de carga como as ferramentas administrativas do cluster. Este é o cenário descrito na primeira parte do artigo, onde sugiro colocar o MySQL Proxy e as ferramentas administrativas do cluster no servidor 192.168.1.5 para montar uma solução completa de balanceamento de carga, tolerância a falhas e replicação dos dados por meio do cluster.
Com isso terminamos a segunda parte do artigo que explica como montar um cluster no MySQL. Nas próximas colunas veremos passo a passo como configurar o serviço de replicação do MySQL.
Fonte: Imasters
Cluster no MySQL – Parte 01
A necessidade de se montar um cluster no MySQL está relacionada à alta disponibilidade das informações e à tolerância a falhas. Com dois ou mais servidores MySQL sendo executados em cluster os dados são automaticamente replicados entre os servidores e cada nó que pertence ao cluster pode ser removido sem afetar a disponibilidade da aplicação.
O MySQL possui recursos para implementar o cluster nativamente, ou seja, não é preciso instalar nenhum software adicional, além da versão do MySQL já preparada para receber o cluster. O nome utilizado para identificar o componente do MySQL que permite a criação de clusters é NDBCluster e funciona como um engine do banco de dados. Neste artigo utilizarei o MySQL versão 5.0.51 sendo executado em servidores Linux com a distribuição Ubuntu 8.04 (Hard Heron).
O conceito de engine pode confundir alguns usuários que estão acostumados com o SQL Server ou mesmo o Oracle, pois estes produtos não permitem que o usuário escolha o engine do banco de dados. A idéia é que cada engine proporcione características próprias que tragam algum benefício. Por exemplo, no MySQL temos um engine que permite a utilização de transações. Para criar o cluster é preciso indicar que as tabelas que apresentaram a replicação automática utilizam o engine NDBCLUSTER. Notem que não é preciso nenhum hardware específico para a criação de um cluster MySQL.
O cluster do MySQL age de forma transparente, ou seja, a aplicação cliente não precisa saber que o cluster do MySQL está sendo utilizado. Esta característica facilita a utilização desta ferramenta e expande o leque de possibilidades tanto para o desenvolvedor como para quem administra o MySQL. Do ponto de vista de desenvolvimento, não há nenhuma mudança significativa: basta apenas continuar conectando em um endereço IP normalmente. Já para quem administra é preciso cuidados especiais, pois algumas configurações não são replicadas pelo cluster. Por exemplo, os logins e as permissões devem ser configuras nos servidores de forma independente.
É possível utilizar o cluster do MySQL em conjunto com o MySQL Proxy, apresentado em uma coluna anterior aqui no iMasters. Como o cluster apenas replica as instruções para todos os nós ele não distribui a carga entre os servidores. A utilização do MySQL Proxy com o cluster fornece a consistência ao ambiente, pois desta maneira o cluster garante que as bases de dados ficaram iguais. Já o MySQL Proxy permite dividir a carga entre os servidores de acordo com alguma regra específica. Porém cabe aqui dizer que o MySQL Proxy possui recursos para programar como será feita a distribuição de carga por meio da programação na linguagem LUA.
Os principais componentes de um cluster MySQL são os nós, ou seja, servidores MySQL já instalados. Também é preciso dispor de um servidor que receberá o serviço de administração do cluster. Este servidor que administrará o cluster não requer um MySQL instalado, pois apenas os arquivos binários do servidor NDBCluster precisam ser executados. É possível realizar a manutenção e checar o status do cluster conectando-se ao servidor NDBCluster, remotamente ou não.
Para entender o exemplo que será apresentado vamos observar o diagrama da Figura 1, que traz um cenário onde um sistema qualquer é utilizado por vários usuários. Neste cenário os clientes utilizam a aplicação normalmente se conectando no servidor Linux chamado ubuntu02 cujo endereço I.P é 192.168.1.25. Este cenário não contém nenhum tipo de replicação, balanceamento de carga ou tolerância a falhas. Caso aconteça alguma indisponibilidade do banco de dados do servidor ubuntu02 o uso da aplicação ficará comprometido.
Figura 1. Ambiente sem balanceamento de carga, replicação e tolerância a falhas.
A partir do ambiente apresentado na Figura 1 vamos montar um cluster com três servidores: um que conterá as ferramentas de administração do cluster e dois servidores MySQL com o mesmo banco de dados que está sendo utilizado pela aplicação. Notem que poderíamos utilizar mais de dois servidores de bancos de dados de acordo com a necessidade. A idéia aqui é que o servidor que conterá as ferramentas administrativas do cluster replique as instruções enviando igualmente os dados entre os dois servidores de bancos de dados de forma simultânea. Desta maneira o cenário contará com a tolerância a falhas, pois se um servidor não estiver disponível o cluster permite que a aplicação ainda continue sendo utilizada, uma vez que um servidor ainda está disponível. A Figura 2 apresenta o cenário com a configuração do cluster.
Figura 2. Ambiente com um cluster MySQL composto de dois nós.
Do ponto de vista da aplicação a única mudança que deve ser feita é a mudança da conexão com o banco de dados: antes a conexão era feita diretamente para o servidor 192.168.1.25 e agora a conexão será para o servidor 192.168.1.15. Novamente, o cluster não requer que o MySQL seja instalado no servidor na qual as aplicações vão se conectar, ou seja, o servidor 192.168.1.15 não precisar ter o MySQL instalado. É preciso apenas contar com os arquivos binários que compõem o serviço do cluster. Estes arquivos binários são encontrados junto com os arquivos de instalação do MySQL.
O funcionamento do cluster evita a falta de sincronia entre os dois servidores. Por exemplo, se um usuário A se conectar ao cluster e fizer uma instrução UPDATE nos dados de uma tabela este UPDATE será automaticamente enviado para os servidores 192.168.1.25 e 192.168.1.35, deixando os bancos de dados em sincronia. Caso algum dos servidores não possa executar a instrução UPDATE por algum motivo um erro é gerado e automaticamente a instrução é cancelada nos dois servidores.
Outra questão a ser considerada é o ponto de falha representado pelo servidor ubuntu01. Se ele ficar off-line a aplicação não poderá se conectar a nenhum dos bancos de dados. Para isso existe como configurar a tolerância de falha para o serviço de cluster em outro servidor de modo que ele detecte esta falha. Porém no exemplo não apresentarei como fazer isso, pois se trata de um tópico mais avançado.
Existem várias formas de se trabalhar com tolerância a falhas nos servidores Linux. Para quem desejar se aprofundar recomendo soluções que envolvem a configuração de endereços I.P virtuais diretamente no kernel. Apenas para referência, uma dessas aplicações que fazem a criação de endereços I.P. virtuais no Linux é o Ultra Monkey com os módulos do kernal IPVS. Outra alternativa mais fácil de se configurar é o pacote do HeartBet + PerlBal
Com isso terminamos a primeira parte do artigo que explicará como montar um cluster no MySQL. Na próxima coluna veremos passo a passo como configurar o MySQL e o serviço de cluster, além da criação do banco de dados e do teste de instruções.
Referência: HOWTO set up a MySQL Cluster for two servers (three servers required for true redundancy):
http://dev.mysql.com/tech-resources/articles/mysql-cluster-for-two-servers.html
Fonte: Imasters
Bancos de dados Gratuitos: Oracle x IBM x Microsoft
As empresas estão cobiçando uma fatia desse mercado gratuito que vem crescendo constantemente para trazer novos adeptos e clientes aos seus produtos, que têm como concorrentes ótimos produtos como MySQL, Firebird e PostGree.
Um dos principais obstáculos encontrados pelas empresas, além de oferecer licenças gratuitas, é como ganhar confiança entre os desenvolvedores Open-Source e produtores independentes de software.
Olhando esse grande problema, a principal tática para conseguir trazer adeptos e futuramente novos clientes, foi utilizar recursos que suas versões pagas utilizam, de forma restrita e limitada, e ao mesmo tempo, usar o peso que o próprio nome da empresa tem no mercado, pois qual produtora de software não gostaria de oferecer seu produto utilizando um banco de dados da Microsoft, Oracle ou IBM?
A primeira empresa a apostar suas fichas foi a Microsoft, trazendo o SQL Server Express, olhando todo esse movimento de marketing em busca de novos clientes do adversário, a Oracle não ficou para trás e lançou o Oracle Express Edition para acompanhar a Microsoft.
A IBM também não queria ficar fora desse jogo, e logo colocou no mercado o IBM Express C, estreitando a fatia de banco de dados Open-Source e aumentando a competição entre as empresas, que já disputam o mercado de licenças pagas.
Com toda essa briga, nos restou saber qual devemos utilizar, já que existem muitas boas opções no mercado, e para conseguir boas soluções em projetos, uma relação dos produtos que possuem versões gratuitas e pagas será comparada a seguir:
Microsoft SQL Server Express
A Microsoft criou SQL Server Express sobre o modelo do seu principal banco de dados, o SQL Server 2005, permitindo uma facilidade de migração para sua versão paga, o SQL Server Express é uma ótima solução para desenvolvedores da plataforma Microsoft, como ASP, Visual Basic e DotNet.
Abaixo seguem alguns recursos que serão encontrados na versão gratuita:
LIMITAÇÃO
Capacidade de Armazenamento: 4GB
Processadores: 1 Processador
Memória: 1 GB
Sistema Operacional: Windows
RECURSOS SUPORTADOS
- Stored Procedures
- SQL Server Configuration Manager
- Views
- Replication *
- Triggers
- Advanced Query Optimizer
- Cursors
- SMO/RMO
- sqlcmd and osql utilities
- Integration with Visual Studio 2005
- Snapshot Isolation Levels
- Service Broker **
- Native XML support, including XQuery and XML Schemas
- SQL CLR
- Transact-SQL language support
- Multiple Active Result Sets (MARS)
- Dedicated Administrator Connection **
- Auto Tuning
- Common Language Runtime and .NET Integration
- Integration with Microsoft Baseline Security Analyzer
* Esse recurso é somente disponível aos usuários que forem assinantes da Microsoft.
** Para utilizar esses recursos há uma limitação, favor consultar a documentação do produto.
Agora, para quem já conhece os recursos do SQL Server, abaixo segue uma relação dos serviços que não são suportados pela versão gratuita:
RECURSOS NÃO SUPORTADOS
- Database mirroring
- SQL Mail
- Online restore
- Fail-over clustering
- Database snapshot
- Distributed partitioned views
- Parallel index operations
- VIA protocol support
- Mirrored media sets
- Log shipping
- Partitioning
- Parallel
- DBCC
- Address Windowing Extensions (AWE)
- Parallel Create Index
- Hot-add memory
- Enhanced Read Ahead and Scan
- Native http SOAP access
- Indexed views (materialized views)
- SQL Mail and Database Mail
- Partitioned views
- Online Index Operations
- SQL Server Agent and SQL Server Agent Service
O problema que a Microsoft pode encontrar para conseguir ganhar espaço nesse mercado é a limitação do seu produto somente em seu próprio sistema operacional Windows, proporcionando custos nos projetos independentes, mas outros pontos positivos podem ser destacados, como:
- Documentação bem elaborada e com exemplos práticos elaborados pelo MSDN.
- Interface gráfica bem fácil de utilizar.
- Administração pelo SQL Server Management Studio Express.
- Integração com a maioria das linguagens de programação do mercado.
Oracle Express Edition
O gigante dos bancos de dados também caprichou na sua versão gratuita, produzindo o Oracle Express Edition (Oracle XE), uma versão que trouxe os recursos mais atualizados encontrados na versão paga do Oracle Database 10G Release 2, a Oracle se destaca por colocar em sua versão gratuita, diversas opções de administração, desempenho, backup e recover, além do Application Express (Apex) um aplicativo de administração de banco de dados desenvolvido para plataforma web, uma customização do seu produto HTMLDB que facilita o gerenciamento do banco de dados e desenvolvimento de pequenos aplicativos para usuários finais, como relatórios e formulários.
Mas, como tudo não é uma maravilha, a Oracle colocou algumas restrições de recursos e limitou seu banco de dados, deixando assim, as produtoras se adaptarem às necessidades do crescimento.
A seguir, estão as limitações e restrições dos recursos que não iremos encontrar no Oracle Express Edition:
LIMITAÇÃO
Capacidade de Armazenamento: 4GB
Processadores: 1 Processador
Memória: 1 GB
Sistema Operacional: Linux ou Windows
Observando as limitações acima, percebe-se que caso sua empresa tenha máquinas poderosas, poderá apenas utilizar os limites impostos, marcando como um ponto negativo, porém outro lado irá lhe recompensar com alguns recursos que somente as versões pagas da Oracle oferecem e outros que somente a versão 10G possui, veja abaixo:
RECURSOS SUPORTADOS
- PL/SQL stored procedures e triggers
- Oracle Developer Tools para Visual Studio.Net
- PL/SQL Server pages
- Active Directory
- PL/SQL native compilation
- DML Triggers
- Drivers JDBC
- Index-organized tables
- Suporte .Net, OLE DB e ODBC
- Temporary table
- Suporte XML
- Objects and Extensibility
- Suporte a LOB (Large Objects)
- Oracle Text
- Function-based index
- SQL Model
- SQL Analytic functions
- Star query transformation
- Globalization support
- Multiple block size support
- Flashback Query
- Online Backup
- Encryption toolkit
- Automatic Memory Management
- External tables
- External procedures
- Distributed transactions
Alguns recursos mais avançados que os profissionais encontram na versão 10G do Oracle não foram disponíveis, como:
RECURSOS NÃO SUPORTADOS
- Automatic Storage Management
- Virtual Private Database
- Database Resource Manager
- Fine grained auditing
- Flashback Transaction Query
- Fast-Start Selectable Recovery Time
- Block-level media recovery
- Parallel backup and recovery
- Point-in-time tablespace recovery
- Trial recovery
- Flashback Table
- Flashback Database
- Online schema reorganization/redefinition
- Parallel export/import
- Parallel statistics gathering
- Parallel query/DML
- Materialized View Query Rewrite
- Summary Management
- Bitmapped index, bitmapped join index
- Data Compression
- SQLJ
- Database Web services
- Java Server Pages
- Java support in the database
Muitos outros pontos positivos podem ser encontrados quando uma empresa pensar em utilizar o Oracle Express Edition em seus projetos, no quais podemos citar alguns, como:
- Documentação On-line no site da Oracle, desde iniciante ao avançado.
- Integração com diversos aplicativos da Oracle para gerenciamento do banco de dados, como: Oracle Enterprise Manager, Apex, SQL Developer e HTML DB.
- Possibilidade de ajustar o banco de dados e sistema operacional para ganhos de desempenho.
- Drivers compatíveis para a grande maioria das linguagens de programação.
- Possibilidade de Cold e Hot backup utilizando o RMAN.
IBM DB2 Express C
A IBM desenvolveu a versão gratuita utilizando os recursos de sua versão paga o DB2 UDB Express com uma configuração de pacote menor, uma vantagem que o DB2 Express-C pode lhe oferecer é realizar a migração do seu banco de dados para qualquer outra versão sem a necessidade da paralisar o aplicativo, deixando o aplicativo 100% operante utilizando uma outra tecnologia de banco de dados.
Com o DB2 Express-C você pode encontrar estabilidade e flexibilidade nos diferentes sistemas operacionais e uma gama de aplicativos para gerenciar de modo ágil e fácil todos os banco de dados DB2.
As limitações do DB2 são diferenciadas e mais poderosas como podemos observar abaixo:
LIMITAÇÃO
Capacidade de Armazenamento: Ilimitada
Processadores: 2 Processadores
Memória: 4 GB
Sistema Operacional: Linux ou Windows
O suporte às mais variadas linguagens de programação e as poucas restrições impostas aos seus recursos tornam mais fortes o seu poder de competição no mercado e um objeto de desejo entre os desenvolvedores, abaixo podemos analisar o que o DB2 Express-C pode nos proporcionar:
RECURSOS SUPORTADOS
- Suporte XML
- Suporte .NET
- C/C++
- Java
- PHP
- Suporte a Unix
- Web Services
- ADO e ADO.NET
- SQLJ
- SQL Embutido
- Gerenciamento Autônomo
- WebSphere Studio Application Developer
Alguns profissionais DB2 gostam de dizer que o DB2 Express-C é um pequeno DB2 UDB Express, pelo motivo que quase todos os recursos são encontrados nessa versão, com exceção dos recursos abaixo:
RECURSOS NÃO SUPORTADOS
- Warehouse Manager tools & servers
- Extender support
- DB2 Connect support
- Informix Data Source Replication
- Replication Data Capture
- APPC
- Netbios
- Database Partitioning Feature
- Connection Concentrator
- DB2 Geodetic Extender
- Query Patroller
- Net Search Extender
- pureXML
- DB2 Web tools
- Spatial Extender Client and Samples
- Microsoft Cluster Server support
Outros pontos devem ressaltar quando pensarmos em utilizar o produto em seus projetos, que podem futuramente trazer beneficios ou problemas:
- Pouca documentação sobre o banco de dados.
- Integração com todos os outros aplicativos do fabricante.
- Possibilidade de adquirir recursos extras, conforme a necessidade do aplicativo.
- Estabilidade, confiabilidade e segurança aos desenvolvedores.
Suporte
Para todos os produtos citados, os fabricantes não fornecem suporte técnico, apenas Fórum em seus respectivos sites gerenciados e administrados por profissionais da empresa, exemplo é o suporte oferecido pela Oracle que pode contar com grandes administradores de banco de dados do mercado (DBA), como Thomas Kyte. A Microsoft criou Hot site com fórum de suporte e artigos técnicos no MSDN, o único que trouxe um pouco de dificuldade foi a IBM, que disponibilizou apenas um fórum técnico em seu site que é difícil ter retornos e quase nenhum artigo técnico.
Custos
Como não há necessidade de adquirir licenças para os bancos de dados, seu custo fica praticamente zero, é o caso quando se utiliza bancos de dados como MySQL, Firebird e PostGree.
Devemos sempre orientar o profissional que utilizar um Oracle, SQL Server ou DB2, que ele pode, sim, envolver custos e fornecer um crescimento ao seu aplicativo. Esses custos podem estar embutidos na compra de máquinas mais poderosas, mão-de-obra qualificada e aquisição de recursos ou serviços extras fornecidos pelo fabricante.
Portanto, antes de querer implantar algum banco de dados, veja a real necessidade do seu aplicativo e analise todas as funcionalidades que cada versão pode lhe oferecer para não ter arrependimento posteriormente. Eles realmente são capazes de trazer muitas melhorias e total estabilidade ao seu aplicativo, mas sempre com cautela.
Download
Abaixo, estão disponíveis todos os links úteis para baixar as versões desejadas.
Biblioteca Técnica
Como as versões dos poderosos bancos de dados gratuitos são muito recentes, encontrar e trocar informações sobre os produtos é muito difícil, então, abaixo segue uma relação de sites e fórum que possuem dicas, artigos técnicos e troca de experiências entre os profissionais.
Microsoft SQL Server Express
Linha de Código
http://www.linhadecodigo.com.br/artigos.asp?id_ac=947&pag=1
MSDN SQL Server Express
http://www.microsoft.com/express/sql/download/
Oracle Express Edition
OTN
http://www.oracle.com/technology/products/database/xe/index.html
Oracle Express Edition Tutorial
http://st-curriculum.oracle.com/tutorial/DBXETutorial/index.htm
Máteria sobre Oracle XE em português
Revista SQL Magazine Edição 35
https://ssl.dominal.com/devmedia/loja/edicoes_anteriores3.asp
IBM DB2 Express-C
Viva o Linux
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=4687
DB2 Universal Database
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/welcome.htm
Arquitetura de Data Warehouse – Parte 01
A escolha da arquitetura é uma decisão gerencial do projeto e está baseada (normalmente) nos fatores relativos à infra-estrutura atualmente disponível (que se for o caso de aquisição do mesmo), ao ambiente de negócios, escopo desejado, além de capacitação dos recursos disponibilizados no projeto e funcionários da empresa projetos para tal investimento.
O DW é projetado e construído com base nas necessidades da empresa como um todo e considerado um repositório comum de dados de suporte à decisão, disponível em toda a empresa.
A arquitetura global pode ser fisicamente centralizada ou fisicamente distribuída nas instalações de uma empresa.
A centralização física é utilizada quando a empresa existe em um único local e o DW é administrado por alguma pessoa ou recurso de TI.
A distribuição física de um DW é utilizada quando a empresa possui diversos locais físicos (instalações) e os dados em múltiplas instalações físicas. Também é administrado por alguém do departamento de TI.
Obs.: Quando o departamento de TI adminstra o DW, isso não quer dizer que o departamento de TI controla o DW. Isso pode ser feito por outro departamento ou até mesmo por uma empresa especializada em controle e administração de DW, pois é ele quem decide quais e que dados irão entrar no DW e quando devem ter a carga incremental (atualização), além de como outros departamentos irão acessar, que pessoas podem acessar os dados, etc.
Dentro desse contexto, resume-se que a implementação e a administração devem ser realizadas por um departamento e profissionais específicos da área de TI, até porque o departamento de TI é o que administra a rede interna de comunicação de dados da empresa.
A figura a seguir mostra a arquitetura de um Data Warehouse, considerando que a implementação é top-down (relembrando o artigo anterior: Top-Down é quando a empresa cria um DW e depois parte para a segmentação, ou seja, divide o DW em áreas menores gerando assim pequenos bancos orientados por assuntos aos departamentos.), ou seja, segundo Inmon, direto ao DW.
Arquitetura de Data Warehouse
Os dados são extraídos de sistemas transacionais (OLTP) e/ou de fontes de dados externas, seja via arquivo local (TXT, XML por exemplo) ou ainda por um ERP.
Os dados são filtrados, sendo eliminados os dados não necessários e realiza-se o processo de ETL, que é a extração, transformação e carga desses dados e metadados, que, então, posteriormente e logicamente, são carregados no DW.
A partir do DW, os dados e metadados são extraídos para os Data Marts (DM), que, por sua vez, as informações estão em maior nível de sumarização e, normalmente, não apresentam o nível histórico encontrado no DW.
Essa implementação tem como lado positivo o fato de “forçar” a empresa a definir regras de negócio de forma corporativa antes de iniciar-se projeto de DW em si.
Vantagens e devantagens dessa arquitetura:
Vantagens:
- Herança de arquitetura: todos os DM originados de um DW utilizam a arquitetura e os dados desse DW, permitindo uma fácil implementação.
- Visão de empreendimento: o DW concentra todos os negócios da empresa, sendo possível extrair dele níveis menores de informações.
- Repositório de metadados centralizado e simples: o DW provê de um repositório de metadados central para o sistema. Essa centralização permite manutenções mais simples do que aquelas realizadas em múltiplos repositórios.
- Controle e centralização de regras: a arquitetura top down garante a existência de um único conjunto de aplicações para extração, limpeza e integração dos dados, além de processos centralizados de manutenção e monitoração.
Desvantagens:
- Implementação muito longa: os DW são, normalmente, desenvolvidos de modo iterativo, por áreas de assuntos, como por exemplo, vendas, finanças e recursos humanos. Mesmo assim, são necessários, em média 15 ou mais meses para que área de assunto entre em produção, dificultando a garantia de apoio político e orçamentário.
- Alta taxa de risco: não existem garantias para o investimento nesse tipo de ambiente.
- Heranças de cruzamentos funcionais: é necessária uma equipe de desenvolvedores e usuários finais altamente capacitados para avaliar as informações e consultas que garantam à empresa habilidade para sobreviver e prosperar na arena de mudanças de competições políticas, geográficas e organizacionais.
- Expectativas relacionadas ao ambiente: a demora do projeto e a falta de retorno podem induzir expectativas nos usuários.
No próximo artigo, continuarei abordando a arquitetura de DW, mais precisamente sobre a implementação Botton Up e de Implementação Combinada.
Referências Bibliográficas:
Tecnologia e Projeto de Data Warehouse, Felipe Nery Rodrigues Machado, 2007.
Acessando configurações do banco de dados no Rails
Toda aplicação Rails possui o arquivo config/database.yml, onde você configura a conexão com o banco de dados nos ambientes de produção, desenvolvimento e teste. O Rails se encarrega de realizar a conexão com o banco de dados quando a aplicação é iniciada (com o WEBrick, por exemplo).
E como fazer caso seja necessário, no seu contexto, ter acesso ao username e password presentes nesse arquivo? Acredito que esses dados não estejam disponíveis em nenhum dos objetos que o Rails instancia (eu procurei), certamente por questões de segurança, mas se você realmente precisa carregar esses dados, eis aqui uma forma bem simples.
De preferência dentro de um controller da sua aplicação (como o ApplicationController), você pode definir esta linha:
class ApplicationController < ActiveRecord::Base
@@db_config = YAML.load_file("#{RAILS_ROOT}/config/database.yml")
[RAILS_ENV]
end
Agora você tem em @@db_config um hash (cujas chaves são strings, e não símbolos) com tudo aquilo que você precisa. Digamos que seu config/database.yml tivesse esta cara:
production:
adapter: mysql
database: teste_production
username: teste
password: teste
timeout: 5000
development:
adapter: mysql
database: teste_development
username: teste
password: teste
timeout: 5000
Se o servidor da aplicação está rodando em modo de desenvolvimento, então a constante RAILS_ENV guarda development. Por conseqüência, @@db_config['database'], por exemplo, guarda teste_development.
Por ter sido declarada no escopo de classe de ApplicationController, nesse exemplo @@db_config estaria disponível em todos os métodos de todos os seus controllers.