Nos últimos dias, várias pessoas perguntaram minha opinião sobre a última versão do MySQL 5.6. Para aqueles que não viram as notícias, a Oracle anunciou sua primeira grande versão do MySQL em dois anos. Uma vez que o NoSQL tem crescido rapidamente em mercados chave onde o MySQL tem sido historicamente forte, penso que não é surpreendente que a Oracle tenha focado muita atenção em resolver as fraquezas que fizeram do NoSQL um sucesso tão grande. Tomas Ulin, vice-presidente de engenharia do MySQL, chega a dizer que "o MySQL pode combinar o melhor dos dois mundos" e "você não precisa mais de dois bancos de dados".
A visão de Tomas e do MySQL sobre o mundo dos bancos de dados parece ser que ele não será diferente do que tem sido nos últimos 40 anos - principalmente que a tecnologia relacional pode fazer tudo e é a tecnologia certa para cada necessidade.
Não acreditamos nisso. Acreditamos que estamos caminhando rapidamente para uma era em que várias tecnologias de banco de dados estão disponíveis para os desenvolvedores de aplicativos, e eles escolherão o banco de dados certo para seus casos de uso e requisitos específicos. Cada tecnologia terá seus pontos fortes e fracos inerentes e oferecerá um conjunto muito diferente de compensações a serem escolhidas. Às vezes, uma tecnologia relacional como o MySQL será mais adequada (certamente não acreditamos que a tecnologia relacional esteja desaparecendo). Outras vezes, um banco de dados de documentos, como o Couchbase, será a opção certa.
É por isso que eu não acho que o MySQL 5.6 terá qualquer efeito sobre o rápido crescimento do NoSQL. A razão pela qual o NoSQL está decolando não é porque ele tem um ou dois recursos interessantes. É porque ele fez um conjunto fundamentalmente diferente de escolhas arquitetônicas e trocas que muitos desenvolvedores de aplicativos preferem para os tipos de aplicativos que estão desenvolvendo hoje. Adicionar um recurso a um banco de dados relacional como resposta ao que as pessoas dizem gostar no NoSQL não vai mudar essas diferenças fundamentais.
Por exemplo, a tecnologia relacional é fundamentalmente uma tecnologia baseada em esquemas de tabelas, linhas e colunas. Adicionar um recurso como a nova linguagem de definição de dados on-line (DDL) no MySQL 5.6 para tornar mais fácil e menos demorado alterar seu esquema não torna um banco de dados relacional sem esquema. Também não aborda o fato de que muitos desenvolvedores acham muito mais intuitivo e produtivo trabalhar com documentos (objetos) em um banco de dados de documentos do que com tabelas em um banco de dados relacional. Portanto, embora esse recurso possa ser útil para os desenvolvedores que escolheram a tecnologia relacional por suas vantagens fundamentais, ele não fará nada para desacelerar a onda de desenvolvedores que mudaram para bancos de dados de documentos (ou outros) NoSQL por suas vantagens fundamentais.
Da mesma forma, com a nova API memcached do MySQL 5.6, pode ser mais fácil para os desenvolvedores acessarem os dados usando as APIs clássicas get e set, mas a implementação é apenas superficial. Os dados que estão sendo armazenados ainda são mapeados para tabelas e colunas na camada de armazenamento. Os desenvolvedores ainda precisam definir seus esquemas de tabela antes de usar essas APIs, o que significa que eles ainda não obtêm a flexibilidade de esquema de que os aplicativos da Web precisam. A fragmentação de dados não estruturados - e que mudam constantemente de estrutura - para que se encaixem em tabelas e colunas é uma abordagem forçada e ineficiente.
Como uma nota lateral, é curioso que a equipe do MySQL pareça estar fora de sintonia com outras partes da Oracle. Enquanto a equipe do MySQL parece estar convencida de que o MySQL pode fazer tudo, a equipe de NoSQL da Oracle parece pensar de forma diferente e está ocupada tentando alcançar os líderes de NoSQL como Couchbase, MongoDB e Cassandra com seu próprio produto NoSQL. Se a tecnologia relacional é uma tecnologia de tamanho único, por que a própria Oracle está fazendo um investimento tão grande no desenvolvimento de seu próprio produto NoSQL?
O que vemos é uma onda totalmente nova de aplicativos que têm requisitos muito diferentes daqueles que os aplicativos tinham há apenas alguns anos. Na maioria das vezes, eles são baseados na nuvem, precisam dar suporte a um número enorme e dinâmico de usuários, precisam armazenar grandes quantidades de dados e precisam de um modelo de dados altamente flexível que lhes permita ajustar-se aos requisitos de captura de dados que mudam rapidamente e processar muitos dados semiestruturados e não estruturados. As decisões arquitetônicas fundamentalmente diferentes incorporadas nas tecnologias NoSQL - juntamente com a escalabilidade fácil, o alto desempenho consistente e as vantagens do modelo de dados flexível (juntamente com todas as outras compensações) que o NoSQL oferece - estão se tornando a melhor opção para um número cada vez maior desses aplicativos.
Isso não significa que o MySQL (ou bancos de dados relacionais) desaparecerá ou não desempenhará um papel significativo no setor de bancos de dados no futuro. Significa apenas que os desenvolvedores terão mais opções (sempre uma coisa boa) e que algumas tendências muito poderosas estão muito bem alinhadas com os pontos fortes da tecnologia NoSQL.
Na minha opinião, o handlersocket (que permite o acesso ao mecanismo de armazenamento sem a camada SQL) foi uma ponte perfeita do tipo NoSQL entre os dois mundos. Preenchendo uma lacuna de produtos que desejam fornecer uma taxa mais alta de acesso a objetos e, ao mesmo tempo, manter os recursos transacionais do mecanismo subjacente. A tentativa da Oracles de ser \"NoSQL\" é muito ruim. Você precisa criar/configurar manualmente mapeamentos para armazenamentos de objetos em um banco de dados especial, e essas tabelas especiais precisam ser definidas de uma maneira específica. Isso é muito restrito.
Com o handlersocket, eu simplesmente abro o banco de dados/tabela de minha escolha e disparo. A grande desvantagem no momento? O handlersocket não será compilado com a versão 5.6 e, até que isso aconteça, não há como aproveitar os benefícios das melhorias que a Oracle fez no nível do InnoDB.
Outro ponto negativo é o desempenho da nova interface nosql do memcache. Em minha máquina com a versão 5.6, ela lida com 500.000 linhas por segundo. O Handlersocket com a versão 5.5 na mesma máquina gerencia 800.000 para o mesmo perfil de dados. Eu gostaria que a Oracle tivesse pegado a bola do Handlersocket e a tivesse usado.