O storage engine, literalmente, motor de armanezamento, ou, carinhosamente, motor como convencionamos chamar no Brasil pode ser entendido, de maneira muito crúa, como sendo tipo de tabela. É uma característica, única e exclusiva do MySQL/MariaDB. E por que não dizer um de seus charmes?

É provavel que, para quem está chegando agora ao mundo dos bancos de dados, seja, relativamente, mais fácil compreender, e até aceitar, o funcionamento dos storages engines. DBA’s mais experimentados, principalmente, egressos do Oracle & DB2, terão mais dificuldade de aceitar o seu funcionamento, do que entendê-lo, propriamente dito.

Em Oracle, DB2, PostgreSQL, Sybase, MS-SQL, enfim em todos os bancos de dados relacionais (RDBMS) quando uma tabela é criada, esta tabela sempre é transacional, e, sempre tem um conjunto fixo de recursos e qualidades. Portanto, podemos assumir que, possuem o mesmo “motor”, ou seja, terão sempre a mesma performance.

Quando se utiliza servidores de ponta, quando grande capacidade de processamento e memória, não há problema nenhum de que todas as tabelas sejam transacionais, portanto, mais pesadas. Lembremos que tabelas transacionais devem contigenciar travamentos, escrever muito mais, em logs de REDO e UNDO, por exemplo, entre outras qualidades típicas de tabelas transacionais.

Em outras palavras, se você só vai rodar em estrada boa (“servidorzão”) com excelente infra, e tem bastante dinheiro no bolso, por que não rodar de Ferrari? Agora, se você irá rodar em estrada esburacada, “terrão”, e pouca “grana”, seria melhor andar de Niva 4×4… ou até de bicicleta, por que não? Tempo… Tempo… Você sabe o que é um Niva? Laughing É um jipinho lazarento, de fabricação Russa. Feio que dói, mas bom de estrada de terra (banco de dados também é cultura).

Isto é storage engine. É você escolher o carro certo (me desculpem, se o Sr. Lula usa futebol em suas metáforas, não posso usar carros?), ou melhor, o tipo de tabela mais adequada à finalidade da tabela em si. É agregar recursos, ou, tirar recursos desnecessários, alijando peso da tabela, deixando-a mais leve e até mais rápida.

Se ainda não entendeu o cerne da coisa. Aí vai outra pérola. Imagine que toda tabela que você cria nos demais bancos de dados é sempre uma Ferrari, com um motorzão, veloz, cheia de itens de luxo – alguns até desnecessários demais -, oops, aliás a cor vermelha, da Ferrari, nos lembra de um determinado banco de dados Wink Agora, imaginem que você tem por objetivo cruzar uma avenida, totalmente, congestionada. Pergunta-se: Quem fará mais rápido, a Ferrari, ou uma magrela (também conhecida por bicicleta)?

Esta é a grande sacada do storage engine. Escolhendo um determinado motor/storage engine, você acrescenta ou retira um grupo de características que deixam as tabelas mais rápidas, por exemplo. Com isso, no MySQL/MariaDB você pode sim, dirigir uma Ferrari (tabelas transacionais) ou pedar de bicicleta (tabelas não transacionais).

Quais são as principais características, recursos ou funcionalidades inerentes aos storage engines/motores:

a) Capacidade Transacional: É a capacidade da tabela aceitar múltiplos acessos (de múltiplos usuários/aplicações), com colisão e travamento mínimos, sem que um usuário interfira com a operação do outro. É poder executar comandos em blocos (transação), ao invés de executar um comando SQL por vez. É estar de acordo com o modelo ACID (Atômico, Consistente, Isolado e Durável). 

b) Meio de armazenamento: Isto é fantástico. Nos outros bancos de dados, toda tabela grava e lê os dados de uma única forma padrão. No MySQL/MariaDB, dependendo do motor escolhido, pode-se gravar a tabela 100% em memória, isto mesmo, nada no disco. Pode-se gravar dados em uma TABLESPACE, como no Oracle, por exemplo. Pode-se se utilizar uma tecnologia dos anos 70, extramente rápida, conhecida como ISAM, para gravar dados e recuperá-los (leitura) de forma muito rápida. Outro tipo de motor pode gravar os dados de forma compactada, como em um arquivo ZIP, economizando muito espaço em disco. Ainda, pode-se gravar em formato CSV que facilita muito a integração com equipamentos de rede e telefonia, por exemplo. E mais, ao invés de ler e gravar os dados no servidor onde o MySQL/MariaDB está instalado, pode-se espalhar os dados por vários computadores para se criar um cluster de alta disponibilidade e alta performance.

c) Índices: Dependendo do motor, temos índices do tipo B-TREE, B+TREE, RTREE (spatial), ou FULL TEXT (que indexa palavras ao invés da coluna ou campo inteiro, e permite buscas como fazemos no GOOGLE, digitando palavras fora de ordem).

d) Integridade Referencial: Estou falando de FK (foreign key). Há motores que usam, e, motores que não usam. Como todos os recursos que estamos discutindo, dependendo da aplicação ou finalidade da tabela isto não é necessário… e é uma funcionalidade que pesa para o banco de dados. Às vezes, não ter este recurso pode ser uma vantagem em termos de velocidade.

e) Tipo de travamento: É a capacidade de poder travar um único registro (linha), vários registros ou a tabela inteira. Cada motor tem um ou mais tipo de travamentos à disposição da tabela.

f) BOL – Backup On-Line: Que ótimo fazer backup on line, com todo mundo trabalhando, sem precisar parar o banco. Lindo? Claro, mas tem um custo alto. Se a sua aplicação não roda H24 (24 horas por dia), significa que você tem janela de backup. Não seria mais lindo se você pudesse abrir mão deste recurso para ter mais agilidade nas leituras e escritas? Bem vindo ao mundo do storage engine.

g) Auto Recovery: Há motores que caso haja uma corrupção de índice, por exemplo, você se verá obrigado a indisponibilizar o banco para rodar um comandinho básico de REPAIR TABLE. Há outros, no entanto, que no máximo você será avisado, através do log de erro, que o MySQL/MariaDB server encontrou uma inconsistência e, já consertou.

Em resumo, storage engine, é muito mais do que, simplesmente, tipo de tabela. É uma característica única e exclusiva do MySQL/MariaDB que permite escolher um conjunto de recursos pré-definidos que melhor atenda aos requisitos e às necessidades de sua tabela, respeitando, o hardware disponível.

Não perca a parte II deste artigo.