Entenda o Storage Engine Blackhole

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Veja neste artigo o Storage Engine Blackhole.

Entenda o Storage Engine Blackhole

Por Wagner Bianchi

Desde alguns anos atrás, o servidor de bancos de dados MySQL está baseado em um padrão em que, ao se definir um projeto, primeiro se busca as características do sistema ou subsistema que será desenvolvido, levantando informações em relação ao seu back-end e depois que tais pontos são definidos, o administrador de bancos de dados pode definir qual Storage Engine utilizar.

Os Storage Engines não passam de módulos que podem ser plugados ao MySQL para que certas características como possuir transação ou não,  integridade referencial ou não, MVCC, ACID, leitura e escrita sequêncial e outras mais que sabemos que motores de armazenamentos nativos como MyISAM, Archive, InnoDB, Federated, Memory e CSV possuem em uma instalação padrão do servidor de bancos de dados de código fonte aberto mais utilizado do mundo.

O poder que o MySQL deu aos seus usuários, os administradores de bancos de dados, de escolherem quais motores de armazenamento ou Storage Engines utilizar, atribuiu a ele o título de Plugable Database, ou seja, você poderá escolher o motor que deseja utilizar em seu projeto, considerando as suas principais características, para que, de forma transparente, este gerencie as tabelas de seu banco de dados.

Além dos vários Storage Engines que estão disponíveis em uma instalação do MySQL, que são os motores chamados de nativos, ainda podemos observar várias outras empresas que escrevem seus próprios motores e plugam estes no servidor de bancos de dados MySQL, oferecendo funcionalidades bem diferentes daquelas existentes em motores nativos. Destes podemos citar Infobrigth, PBXT, XTradb, Drizzle, Amazon AW3, Google e vários outros.

Este artigo surgiu da vontade de trazer à público uma dúvida levantada por vários profissionais que me enviam por e-mail a mesma pergunta ao enviar o comando SHOW ENGINES, através do mysql client ou mesmo através de qualquer GUI: "O QUE É ESSE TAL DE BLACKHOLE?".
A resposta a essa pergunta se inicia agora.

sql-26-09-2009pic01.JPG

Perceba que na saída do comando SHOW ENGINES, temos a coluna comment que nos descreve as características, bem a "grosso modo" em relação a cada motor nativo do MySQL. Quando chegamos na descrição ou comentário na linha do BLACKHOLE, percebemos que, tudo que escrevermos para uma tabela controlada por este motor de armazenamento vai desaparecer. UAU?!?!? Mas, para que serve isso? Muito bem!

mysql> CREATE TABLE tab_blackhole (
    ->   id int not null auto_increment primary key,
    ->   nome char(40)
    -> ) ENGINE=BLACKHOLE;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into tab_blackhole set nome ='IMASTERS';
Query OK, 1 row affected (0.01 sec)

mysql> select id, nome from tab_blackhole;
Empty set (0.00 sec)

A tabela acima foi criada no banco de dados "test". Como sabemos que ao criar um banco de dados no MySQL, um novo diretório é criado sob o DATADIR ou diretório de dados, dentro do diretório "test", localizado em /var/lib/mysql, foi criado um arquivo nome_da_tabela.frm. Para verificar as variáveis de ambiente que estão setadas no arquivo de configurações my.cnf ou my.ini, utilize o utilitário de linha de comando que é disponibilizado na insta;ação do servidor de bancos de dados MySQL, my_print_defaults, que recebe como parâmetro o agrupamento que desejamos verificar:

shell>  my_print_defaults mysqld

--default-character-set=latin1

--server-id=1

--tmpdir=/tmp

--basedir=/usr

--datadir=/var/lib/mysql

--key_buffer=512M

--read_buffer_size=32M

--read_rnd_buffer_size=16M

--sort_buffer_size=32M

--join_buffer_size=32M

--max_allowed_packet=128M

--table_cache=4000

--sort_buffer_size=512K

Em um ambiente de replicação entre servidores de bancos de dados MySQL, tal Storage Engine poderá ser muito útil quando necessitamos tirar dos usuários em um determinado local as chances de lerem ou alterarem as informações do banco de dados. É bem verdade que se este mesmo usuário "mexer" mais um pouco ele acaba buscando alguma solução “sacana” para fazer alguma bagunça, mas com algum planejamento, o BLACKHOLE lhe ajudará com este feito de esconder os dados de usuários mal ou bem intencionados.

Imagine que a tabela que criamos no exemplo, a tabela tab_blackhole receba vários dados e estes atualizam o estado do banco de dados, ou seja, alteram de alguma forma os dados. Levando em consideração que o log binário esteja habilitado no arquivo de configuração – my.cnf ou my.ini - por causa do esquema de replicação, todos os comandos que atualizam o banco de dados vão ser escritos neste log, sendo que, ao serem escritos, conseqüente mente serão lidos pelo servidor SLAVE que por sua vez pode contar com tabelas MyISAM ou InnoDB, estas que mantém os dados de forma normal. Localmente não temos os dados, já que optamos por utilizar tabelas controladas pelo Storage Engine Blackhole, mas no servidor de bancos de dados SLAVE nós temos acesso a estes.

sql-26-09-2009pic02.JPG

No caso de possuirmos tabelas controladas pelo Storage Engine Blackhole em nosso banco de dados, saiba que não faz sentido contar com TRIGGERS de DELETE ou UPDATE, pois, nesta tabela não há linhas para atualizar ou excluir. O evento da TRIGGER não é disparado, diferentemente de TRIGGERS para INSERT, que trabalha como esperado. Para algumas operações em um ambiente replicado, este motor de armazenamento poderá contribuir para o aumento de performance.

No próximo artigo, vamos falar mais de recursos interessante do MySQL.

 

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?