A característica mais bacana do MySQL/MariaDB, em minha opinião, é o conceito de storage engine, ou, motor como convencionamos aqui no Brasil. Eu gosto de comparar o storage engine com aqueles famosos relógios que trocam de pulseira. O núcleo do relógio é o mesmo, mas, com um visual todo diferente. E, qualquer um pode criar sua pulseira e acrescentá-la ao seu relógio.

Assim é o storage engine. Empresas, comunidades, grupos ou pessoas, individualmente, podem criar um storage engine especilizado com novas funcionalidades, mais performático, orientado para tarefas específicas, e, simplemente, plugá-los no MySQL/MariaDB.

 

O resultado prático disto é que voce continua a usar os comandos SQL ANSI, e todo o repertório de comandos e funções do MySQL/MariaDB, porém, os dados são gravados e lidos de forma diferente, tarefa esta, ao storage engine. E isto, pode se traduzir em novas funcionalidades, ou, em última instância um ganho de performance.

 

O PBXT 

 O PBXT foi desenvolvido pela empresa PrimeBase Technologies, de Paul McCullagh. Seu objetivo é ser um storage engine transacional de alta performance, para ser utilizado tanto operações OLTP. É gratuito, sendo uma alternativa ao innoDB. A principal promessa de Paul (sempre muito solicito e acessível) é de entregar um storage engine, conceitualmente, bastante diferente dos demais, com alta perfomance.

 

Aquecendo os motores

 Esqueça utilizar o PBXT em equipamentos com pouca memória disponível. Se o InnoDB gosta de memória, o PBXT “gostcha muitcho” mais! E, a configuração padrão que vem com ele só serve para irritá-lo, você ficará mais do que desapontado com a performance. Para fazer um uso adequado do PBXT dê especial atenção às seguintes configurações (variáveis mágicas), antes de começar a brincar:

   – pbxt_record_cache_size: Adoro estes nomes auto-explicativos… Este cache (ou buffer) armazena páginas de registros de todas as tabelas PBXT de um dado servidor mysqld. Faça o maior possível (respeitando os limites de seu recurso físico). Quanto maiores suas tabelas, maior deve ser este cara. E quanto maior for este cara, maior a performance obtida. O padrão é 32MB, e, acredite não dá para ser feliz com este tamanho.

   – pbxt_log_cache_size: Este é o cache (ou buffer) de transação. Portanto, quanto maiores suas transações e/ou dado seu alto volume, faça este cache maior possível afim de abrigar as transações em curso. Esta cache afeta, sobretudo, escritas. Seu padrão é 16. O próprio Paul me aconselhou a utilizar um tamanho fixo de 128MB, quando lhe falei do bechmark que eu realizaria.

   – pbxt_index_cache_size: Aqui são armazenadas as páginas de índices, de maneira rude, uma espécie de key_buffer_size (do myisam). O padrão é horrorosos 16MB. Ainda, de acordo com o pai da criança, deve-se usar algo entre 1/3 e 1/2 do tamanho do record cache. É lógico que isto vai depender, e muito, da quantidade de índices envolvidos.

 Sempre gosto de lembrar do lema do MySQL (para que a Oracle jamais se esqueça disto): “ser o melhor banco de dados, e, ser acessível e disponível a todos”. Acho fantástico quando encontro websites desenvolvidos por adolescentes e que utilizam MySQL. Assim como, sites como o wikipedia que usam, exatamente, o mesmo banco de dados. Isto é acessibilidade de inclusão digital no melhor conceito e definição de suas palavras.

  Mysql/MariaDB é fácil, é simples, é eficiente. Detratores a parte. Funciona para quem conhece tudo, ou, para quem faz de conta que conhece, como este que lhes escreve. Não é possível aceitar (me desculpe Paul, sinceramente) que um storage engine venha de fábrica com configurações que não irão funcionar adequadamente. Esta é uma lição de casa para a galera da PrimeBase Technologies.

 

O Rally

 Quem já leu algum benchmark, ou, já assistiu às minhas aulas de performance tuning irá conhecer a minha boa e velha tabela de testes, segue a estrutura utilizada:

CREATE TABLE `telpbxt` (

`cpf` bigint(20) DEFAULT NULL,

`nome` varchar(100) DEFAULT NULL,

`log` varchar(100) DEFAULT NULL,

`endereco` varchar(100) DEFAULT NULL,

`comp1` varchar(100) DEFAULT NULL,

`comp2` varchar(100) DEFAULT NULL,

`bairro` varchar(100) DEFAULT NULL,

`cidade` varchar(100) DEFAULT NULL,

`cep` varchar(100) DEFAULT NULL,

`ddd` varchar(100) DEFAULT NULL,

`telefone` varchar(100) DEFAULT NULL,

KEY `idx2` (`nome`(10))) ENGINE=PBXT DEFAULT AVG_ROW_LENGTH=94 CHARSET=latin1; 

 Especial atenção ao AVG_ROW_LENGTH que representa o comprimento médio de suas linhas (ou registros). É essencial dizer ao PBXT qual o tamanho médio de suas linhas caso você queira andar mais rápido. 

  Esta tabela tem 10.300.000 linhas. Belezinha, ham? Hey, nada de pegar no meu pé por causa deste monte de varchar 🙂 É uma tabela para fins didáticos 🙂

  Uso de disco. Em MyISAM a mesma tabela consumiu 960M, em InnoDB 680M (usando Barracuda). Em PBXT se foram 1.1G. É, praticamente, o dobro do espaço de armazenamento usado pelo InnoDB em sua versão mais atualizada. Tenha em mente que o InnoDB padrão usa ume metódo de compressão dos dados menos eficiente (Antelope).

   Algumas pessoas criticaram este teste pelo tamanho e tipo da tabela. Ora, meu compromisso é com meus colegas de comunidade. Faz sentido testar um storage engine transacional com tabeluchas de 1M? Creio que não. Portanto, vai levar porrada!!! 🙂

   Importante ressaltar que os testes foram realizadas em meu bom e velho MacBook, e não em um hardware class server. No entanto, quando dos testes tudo quanto possível foi eliminado da memória. E toda a majestade e plenitude de meus infindáveis 4G de RAM foram dedicados aos testes. 

 

A Performance

  A comparação foi feita contra os motores MyISAM e InnoDB “tchunados” à excelência (se é que algum dia eu consegui este tipo de coisa). Isto significa que quando testei MyISAM, configurei o servidor para rodar 100% MyISAM, a, mesma coisa para InnoDB e PBXT. Assim, garanti que cada storage engine estava bem atendido quanto aos requisitos de memória e hardware.

  Como era de se esperar o MyISAM andou na frente, muito na frente, do PBXT em todos os quesitos. O InnoDB também foi mais rápido em todos os quesitos, exceto na inserção, surpreendentemente.

   Para inserção, ele andou em média 12% mais rápido que o InnoDB. Veja alguns números:

   Foram inseridas 250.000 em 4.8s, 500.000 em 16.1s, 1 milhão em 39.3s e 3 milhões em 161.4.s. Para um MacBook não está bom? Acho que está excelente. Isto prova que, o PBXT enquanto storage engine transacional está indo em um bom caminho.

    Um simples SELECT COUNT(0) foi respondido em 5.48s contra 6.5s do InnoDB. Agora, um SELECT cep, COUNT(0)…GROUP BY 1 levou 11 minutos contra 7 do InnoDB. É muita diferença. Em tempo, ambas tabelas sem índice.

    A criação de índice tomou 5 horas no PBXT contra 20 minutos do InnoDB.

    Leitura não é o forte deste storage engine, ao menos, não em um MacBook com não mais de 2.5G disponíveis. Conversando com o Paul, sobre os resultados, ele me garantiu que em um equipamento mais parrudo, com bastante memória, o PBXT performaria melhor. Hey, mas, rodei os mesmos testes em MyISAM e InnoDB no mesmo Mac e os resultados foram muito melhores!!!

   Se seu caso é crítico em escrita, provavelmente, este é o motor dos seus sonhos. Fico pensando em dois queridos amigos, um de Porto Alegre e outro de Boa Vista, que tem aplicações que adoram escrever. Este é o seu storage engine.

 

Estabilidade

   De novo. Rodei os testes em meu super mainbook ou noteframe 🙂 Que é bem estável. Faço testes e benchmarks o tempo todo. E, raramente, experimento algum tipo de instabilidade.

   O PBXT tem um sério problema com usuários (como eu) que adoram dar Kill -9 em tudo. Aliás, se alguém descobriu algum Kill -qq coisa para matar as contas e despesas do mês, por favor, me informem. Dirty Shutdown irá custar caro. Portanto, se voce pretende rodar PBXT em um ambiente com alguma instabilidade, repense tudo. Para rodar PBXT, eu aconselho uma bela caixa (hardware), muito bem configurada, estressada à exaustão antes de entrar em produção, e, acima de tudo um sistema no-break, muito, mas muito decente.

   Simulando perda de energia e instabilidade no OS, amarguei, com a única tabelinha usada nos testes com um tempo de reboot de 1:55h! Assustou? Eu também, numa simples tabela de 1G, o tempo de verificação (crash recovery) é de aproximadamente 2 horas. Para efeito de comparação, tive que ser bastante criativo para conseguir fazer o InnoDB entrar em modo de recuperação (RMS – Recovery Management System)…e levou apenas 10 minutos para verificar se estava tudo OK.

   Cabe lembrar que, storage engines que tem algum gatilho para verificação e/ou recuperação, automática, de suas tabelas não liberam o uso do RDBMS enquanto não terminam seus protocolos. Portanto, em meu caso, o PBX me deixava de castigo quase 2 horas toda vez que “crashava” (verbo transitivo direto… quem crash crasha alguma coisa, epa, tá no dicionário, pode procurar…).

 

PROS

   Acessibilidade e disponibilidade do Paul e da PrimeBase Technologies. Velocidade de escrita. 100% ACID. Simplicidade e analogia das variáveis de configuração. CHECK TABLES mais amplo (escreve alguns detalhes importantes no error log).

 

CONS

   Configuração Default. Do excesso de propaganda que é escrita no error log durante a inicialização do mysqld. Facilidade para entrar em modo de recuperação (mesmo sem ter havido escrita na tabela). Tempo de start-up após um dirty-shutdown.

   Não gostei nem um pouco da performance de leitura nem do tempo para manutenção de índices.

 

Recomendação

   Se fosse boa eu estaria vendendo, certo? 🙂

   O PBXT está em desenvolvimento. E para quem já usou ele no ano passado notará profundas melhorias. Mas, ainda não está no ponto de colocar em produção. Agora, se formos analisar a documentação, notaremos que para tabelas muito menores, no máximo 200M ou 300M, teríamos uma performance muito superior. O PBXT é muito calçado em seus caches, portanto, para tabelas que consigam ser, maximamente, populadas no cache de registros, a performance será muito melhorada.

   Não aconselho seu uso até que um novo benchmark seja efetuado.