O estado do NoSQL

Após pelo menos quatro anos de duras críticas, é hora de uma posição mais sólida sobre o estado do NoSQL. Tanta coisa aconteceu em torno do NoSQL que é difícil conseguir uma visão geral e avaliar quais objetivos foram alcançados e em que o NoSQL não deu resultados.

Em muitos setores da indústria e também no meio acadêmico o NoSQL foi mais do que bem sucedido. As universidades estão começando a entender que o NoSQL deve ser cada vez mais adotado na ementa do curso. A estrutura currícular simplesmente não é suficiente para ensinar tudo sobre normalização de banco de dados. Isto, naturalmente, não significa que uma base profunda em modelos relacionais esteja errada. Ao contrário, NoSQL é certamente uma adição perfeita e importante.

O que aconteceu?

O universo NoSQL explodiu em apenas 4 ou 5 anos para cerca de 50 a 150 novos bancos de dados. O site nosql-database.org lista cerca de 150 desses bancos de dados, incluindo alguns "dinossauros" bem antigos, mas ainda fortes como bancos de dados orientados a objetos. E, claro, algumas fusões interessantes aconteceram, como o CouchDB e Membase dando origem ao CouchBase.

Muita gente presumiu que haveria uma enorme consolidação do NoSQL. No entanto, isso não aconteceu. O domínio do NoSQL simplesmente explodiu e ainda está explodindo. Tal como acontece com todas as áreas da ciência da computação − como, por exemplo, linguagens de programação − existem cada vez mais ramificações que se abrem para uma enorme quantidade de bancos de dados. E tudo isso está em sintonia com a explosão da Internet, do big-data, dos sensores e de várias outras tecnologias no futuro, levando a mais dados e diferentes requisitos sobre como tratá-los. Nos últimos quatro anos, vimos apenas um sistema de grande porte saindo de cena: o banco de dados alemão orientado a grafos Sones. A grande maioria dos bancos de dados NoSQL continuam a viver felizes tanto no domínio do código aberto, sem qualquer reviravolta considerável envolvendo dinheiro, quanto no domínio comercial.

Visibilidade e dinheiro

Outro ponto importante é a visibilidade e adoção da indústria. Nesse espaço é possível notar uma grande diferença entre a velha indústria − protegendo o investimento − e a nova indústria: sobretudo startups. Embora quase todas as startups web que se destacaram, como Pinterest ou Instagram, possuem uma arquitetura hibrida (SQL + NoSQL), a "velha" indústria ainda se esforça com a adoção do NoSQL. Mas a observação aqui é que mais e mais empresas como estas estão tentando projetar que parte de seus fluxos de dados sejam processados ​​e posteriormente analisados ​​com soluções NoSQL como Hadoop, MongoDB, Cassandra, etc.

E isso leva também a um aumento forte na demanda por desenvolvedores e arquitetos com conhecimento em NoSQL. Uma pesquisa recente mostrou as seguintes habilidades requeridas ultimamente pela indústria:

1. HTML5
2. MongoDB
3. iOS
4. Android
5. Aplicações para dispositivos móveis
6. Puppet
7. Hadoop
8. jQuery
9. PaaS
10. Mídia social

Há dois bancos de dados NoSQL entre os dez primeiros para os requisitos de tecnologia na lista acima, e um até mesmo antes de iOS. É impossível não enaltecer tal fato.

Mas a adoção do NoSQL está indo mais rápida e profunda do que se poderia pensar à primeira vista. Em um documento técnico (whitepaper) bem conhecido, a Oracle afirmou em meados de 2011 que bancos de dados NoSQL se pareciam com um sabor de sorvete, mas que não se deveria apegar neles porque poderiam não durar muito tempo. Apenas alguns meses depois a Oracle exibiu sua integração com Hadoop com a solução Big Data Appliance. E mais ainda, a Oracle lançou seu próprio banco de dados NoSQL, um BerkeleyDB revisado. Desde então, tem havido uma corrida de todos os fornecedores para uma integração com o Hadoop. Microsoft, Sybase, IBM, Greenplum, Pervasive e muitos outros já possuem forte integração. É um padrão que pode ser visto em toda parte: se não pode lutar contra é melhor se unir a eles.

Mas um dos sinais mais fortes porém silenciosos de uma adoção ampla do NoSQL é que bancos de dados NoSQL estão se tornando um padrão PaaS (plataforma como serviço). Graças à facilidade de configuração e gerenciamento de muitos bancos de dados NoSQL, bancos como Redis ou MongoDB podem ser vistos em dezenas de serviços PaaS como Cloud-Foundry, OpenShift, dotCloud, Jelastic etc. Como tudo se move mais e mais para a nuvem, torna-se um grande momento para o NoSQL colocar pressão sobre os grandes bancos de dados relacionais. Ao existir a opção de escolha entre o MySQL/PostgreSQL ou MongoDB/Redis, por exemplo, vai forçar os usuários a pensar duas vezes sobre o seu modelo, requisitos e a levantar outras questões importantes.

Um outro indicador interessante sobre tecnologias é o radar da ThoughtWorks, que pode trazer informações relevantes, mesmo para quem não concorda totalmente com todo seu conteúdo. Abaixo um radar de outubro de 2012 na figura 1:

Figura 1: Radar de plataformas da ThoughtWorks, outubro de 2012

Em seu quadrante de plataformas são listados cinco bancos de dados:

1. Neo4j (adopt − em adoção)
2. MongoDB (trial but close to adopt − em experimentação mas próximo de adotar)
3. Riak (trial − em experimentação)
4. CouchBase (trial − em experimentação)
5. Datomic (assess − em avaliação)

Nota-se que pelo menos quatro desses bancos receberam muito capital de investimento. Somando todo capital de investimento em todo o espaço NoSQL certamente se chegará em algo entre 100 mil dólares e 1 bilhão de dólares! Neo4j é um de um desses exemplos, recebendo 11 milhões de dólares em financiamentos série B (termo financeiro para designar uma segunda rodada de investimento). Outras empresas que receberam entre 10 e 30 milhões de dólares em financiamento foram: Aerospike, Cloudera, DataStax, MongoDB, CouchBase etc. Olhando novamente a lista com atenção: Neo4j, MongoDB, Riak e CouchBase têm estado neste espaço nos últimos quatro anos e têm provado constantemente estar entre os líderes de mercado para necessidades específicas. Então, o quinto banco de dados da lista, o Datomic, é mais do que surpreendente, um completo e novo banco de dados, com um novo paradigma completo escrito por uma pequena equipe. Ele deve se destacar e será abordado mais adiante ao discutir todos os bancos brevemente.

Padrões

Muitas pessoas têm pedido por padrões NoSQL, mas esquecem de ver que o NoSQL abrange uma gama muito ampla de modelos e necessidades. Desta forma as linguagens unificadas para todas as principais áreas como Wide Column, Key/Value, bancos de dados orientados a documentos e a grafos certamente não estarão disponíveis por muito tempo porque é impossível cobrir todas as áreas. Várias abordagens, como Spring Data, tentam adicionar uma camada unificada, mas cabe ao leitor testar se essa camada é um avanço na construção de um ambiente de persistência poliglota ou não.

A maior parte dos bancos de dados orientados a documentos e a grafos têm surgido com padrões em seus próprios domínios. O universo dos bancos de grafos é mais bem sucedido com projetos como Tinkerpop Blueprints, Gremlin, Sparql e Cypher. No domínio de bancos de dados de documentos existem o UnQL e o jaql preenchendo alguns nichos, embora o primeiro careça de suporte por um banco de dados NoSQL do mundo real. Porém, com a força do Hadoop, muitos projetos estão trabalhando na transição de famosas linguagens de ETL, como Pig ou Hive, para outros bancos de dados NoSQL. Assim, o mundo de padrões está altamente fragmentado, mas apenas devido ao fato de que NoSQL felizmente corresponde a uma área muito ampla.

O cenário

Uma das melhores sínteses do cenário de bancos de dados foi dada por Matt Aslett em um gráfico criado para um relatório do 451 Group. Ele recentemente atualizou o gráfico, separando-o em categorias de bancos de dados e que nos trazem ainda mais percepções. Como pode ser visto na imagem a seguir, o cenário é altamente fragmentado e as categorias se sobrepõem:

Figura 2: O cenário de bancos de dados por Matt Aslett (451 group)

Como se pode ver, existem várias dimensões em uma só imagem: relacional versus não-relacional, analítico versus operacional, NoSQL versus NewSQL. As duas últimas categorias têm as conhecidas sub-categorias de bancos baseados em chave-valor, orientados a documentos, a gráfos e Big Table para NoSQL e Storage-Engines, Clustering-Sharding, novos bancos de dados e soluções de serviços em nuvem. A parte interessante da imagem é que está cada vez mais difícil colocar um banco de dados em uma localização exata na figura. Todo mundo está tentando agora intensamente integrar recursos de bancos de dados encontrados em outros espaços. Sistemas NewSQL implementam características principais NoSQL. Sistemas NoSQL tentam mais e mais implementar recursos "clássicos" como suporte SQL ou "ACID", ou, pelo menos, uma persistência configurável.

Tudo começou com a integração com o Hadoop que diversos bancos de dados relacionais oferecem agora. Mas há muitos outros exemplos: por exemplo, o banco de dados MarkLogic está começando agora a aproveitar a onda do JSON tornando-o difícil de posicionar. Além disso, mais bancos de dados multi-modelo aparecem, tais como: ArangoDB, OrientDB ou AlechemyDB (que agora é uma parte do promissor Aerospike DB). Eles permitem começar com um modelo de banco de dados (por exemplo, documento / modelo JSON) e adicionar outros modelos (grafos ou key-value), conforme novas exigências aparecem.

Livros

Outro grande sinal maravilhoso de um começo de maturidade é o mercado de livros. Depois de dois livros alemães publicados em 2010 e 2011, outro que se viu foi o livro Wiley por Shashank Tiwari. Estruturado como um furacão e repleto de grandes percepções profundas. A corrida continuou com dois livros bons em 2012. O livro "Sete bancos de dados em sete semanas" é certamente uma obra-prima. Recém-escrito e repleto de visões 'hands-on' práticas: ele aborda seis bancos de dados NoSQL famosos e acrescenta PostGreSQL à mistura, tornando-se uma forte recomendação. Por outro lado, P.J. Sandalage e Martin Fowler têm uma abordagem mais holística para cobrir todas as características e ajudar a avaliar o seu caminho e suas decisões com NoSQL.

Mas há mais por vir. É apenas uma questão de tempo até que um livro de Manning apareça em cena: Dan McCreary e Ann Kelly estão escrevendo um livro chamado: "Making Sense of NoSQL" (NoSQL fazendo sentido) e os primeiros capítulos MEAP (Manning Early Access Program) já estão disponíveis.

Depois de começar com conceitos e padrões, seu capítulo 3 certamente parecerá atraente:

• Construindo soluções NoSQL Big Data;
• Construindo soluções NoSQL de busca;
• Construindo soluções NoSQL de alta disponibilidade;
• Usando NoSQL para aumentar agilidade.

Esta é uma nova abordagem e certamente a leitura valerá a pena.

O estado dos líderes

Vamos fazer uma consideração rápida sobre cada líder em NoSQL. Como um dos líderes de mercado mais evidentes, o Hadoop é um "ser estranho". Por um lado, tem um enorme impulso. Como mencionado anteriormente, cada fornecedor de banco de dados clássico está com pressa em anunciar suporte ao Hadoop. Empresas como a Cloudera e MapR continuam a crescer e novas extensões do Hadoop e sucessores são anunciados a cada semana.

Mesmo Hive e Pig continuam ainda a obter melhor aceitação. No entanto, há uma pedra no sapato: as empresas ainda se queixam sobre uma bagunça não estruturada (arquivos de leitura e parsing poderiam ser ainda mais rápidos), MapReduce é "batch demais" (até mesmo o Google continua longe dele),

O segundo líder, MongoDB, também sofre de discussões sem sentido, e pode ser a natureza das coisas que levam DBs receberem maiores críticas. No entanto, o MongoDB segue em ritmo acelerado e as críticas na maior parte são:

a) No que diz respeito às versões antigas ou

b) Devido à falta de conhecimento em como lidar com a solução de maneira correta. Isso recentemente culminou em reclamações absurdas de que a versão de 32 bits pode manipular apenas 2GB, embora o MongoDB afirma isso claramente na seção de download e recomenda a versão de 64 bits.

De qualquer maneira, parceiros do MongoDBs e injeções de capitais ajudaram a criar roadmaps ambiciosos com novidades que chamam a atenção:

• A indústria solicitou alguns recursos de segurança/LDAP que já estão sendo desenvolvidos;
• A pesquisa completa de texto (Full text search) chegará em breve;
• V8 para MapReduce está a caminho;
• Mesmo em um nível mais fino, "Collection level locking" virá;
• E, por fim, uma Shard Hash Key está a caminho.

Especialmente este último ponto desperta o interesse de muitos arquitetos. MongoDB foi muitas vezes acusado (também pelos concorrentes) por não implementar um hashing consistente e conciso, o que não é inteiramente correto dizer, pois tal chave pode ser facilmente definida. Mas, no futuro, haverá uma configuração para uma hash shard key. Isso significa que o usuário é quem decide se uma hash key para sharding é útil ou se precisa (mesmo raramente) de algumas vantagens de escolher sua própria chave sharding. Certamente isso aumenta a pressão sobre outros fornecedores e conduzirá à discussão proveitosa de quando usar uma sharding key.

O Cassandra é o próximo na fila e ele tem ido muito bem, adicionando mais e melhores ​​características como melhores consultas. No entanto, os rumores não pararão tão cedo a respeito da execução de um cluster Cassandra, que não é muito fácil e requer algum trabalho duro. Mas a questão mais interessante aqui certamente diz respeito ao DataStax. A nova companhia no topo do Cassandra − 25 milhões de financiamento round C − está abordando principalmente análises e alguns problemas operacionais. As análises surpreenderam muitos, porque no princípio o Cassandra não era conhecido como um mecanismo de consulta poderoso. Mas, como isso mudou na última versão, os recursos de consulta podem ser suficientes para algumas análises modernas.

A velocidade de desenvolvimento do Redis também é notável. Apesar das afirmações de que Salvatore não teria alcançado nada sem a comunidade e a ajuda de Pieter Noordhuis, ele ainda se parece com um deslumbrante homem show. O sentinela de failover e scripts do lado do servidor com a linguagem de programação Lua são as mais recentes conquistas. A decisão por Lua foi um pouco chocante para a comunidade porque todo mundo integra JavaScript como uma linguagem server-side. No entanto, Lua é uma linguagem limpa e vai ajudar o Redis abrir uma nova pandora de possibilidades.

O CouchBase também se parece com uma solução brilhante em termos de escalabilidade e latência, apesar dos fortes ventos que Facebook e, portanto, Zynga estão enfrentando agora. Não é certamente uma máquina de consulta "quente", mas se puderem melhorar a consulta no futuro, o portfólio estará bastante completo. A fusão com os fundadores do CouchDB foi definitivamente um passo firme e vale a pena ver as grandes influências do CouchDB no Couchbase. Em cada conferência de banco de dados também é "engraçado" ouvir as discussões, se CouchDB está melhor ou pior depois de Damien, Chris e Jan terem saído. Algumas pessoas até podem dar ouvidos às opiniões por aí, mas quem se importa, desde que o DB esteja indo bem. E parece que ele está.

O último DB NoSQL a ser mencionado aqui é naturalmente o Riak, que também melhorou drasticamente em termos de funcionalidade e monitorização. O Riak continua tendo uma boa reputação principalmente em termos de estabilidade: "rocha sólida, invisível e boa para o sono". O fork Riak CS também parece interessante em termos da modularidade dessa tecnologia.

Interessantes recém-chegados

Além dos líderes de mercado, avaliar os recém-chegados também é sempre interessante. Vamos ver mais a fundo alguns deles.

O Elastic Search é certamente um dos mais novos produtos NoSQL e acabou de obter $10 milhões em financiamento de série A, e isso ocorreu por uma boa razão. Por ser um mecanismo de busca escalável em cima do Lucene, ele traz diversas vantagens como: a) uma empresa de primeiro nível na prestação de serviços e b) aproveita todas as conquistas que o Lucene tem concebido nos últimos anos. O Elastic Search certamente irá se infiltrar na indústria agora cada vez mais, atacando todos os grandes "jogadores" na área de informação semi-estruturada.

O Google também traz o seu pequeno, mas rápido, LevelDB para o campo de batalha. E ele serve como base para muitas aplicações que necessitam de requisitos específicos, tais como integração de compressão. Mesmo o Riak integrou o LevelDB. Ele continua a ser visto mesmo quando todas as novas bases de dados internas do Google, como Dremel ou Spanner, encontrarão seu caminho para fora da empresa na forma de projetos open-source (como o Apache Drill ou Cloudera Impala).

Outra mudança tectônica certamente foi o DynamoDB, no início de 2012, considerado o serviço que mais cresce já lançado pela Amazon. É a máquina de escalar final. Novos recursos estão chegando lentamente, mas o foco em SSDs e latência é muito surpreendente.

Os banco de dados multimodelo também são de um segmento do qual vale a pena dar uma olhada. O OrientDB, seu representante famoso, nem de longe é um recém-chegado, além de estar melhorando suas capacidades muito rapidamente. Talvez em ritmo rápido demais, porque alguns clientes devem estar felizes pois o OrientDB chegou à versão 1.0 (1.3 quando da tradução do artigo) e, portanto, espera-se que tenha aumentado muito mais a estabilidade. Suporte a grafos, documentos, chave-valor, combinados com transações e SQL são motivos suficientes para dar-lhe uma segunda chance. Especialmente o bom suporte SQL o torna interessante para as soluções analíticas, tais como Penthao. Outro recém-chegado neste espaço é ArangoDB que está se movendo rápido e não recua ao se comparar em benchmarks contra os players estabelecidos.

No entanto, novamente o JSON nativo e o suporte a grafos poupam muito esforço se novos requisitos têm de ser implementados e os novos dados têm um modelo diferente que deve ser persistido.

De longe, a maior surpresa deste ano foi o Datomic. Escrito por alguns "rock stars" da linguagem de programação Clojure e em um curto espaço de tempo incrível. O Datomic revela uma porção de novos paradigmas, além disso, construiu o seu caminho até chegar no radar ThoughtWorks com a recomendação "fique de olho nele". E apesar de ser "apenas" uma camada em cima de bancos de dados estabelecidos ele traz uma enorme quantidade de vantagens, tais como:

• transações;
• uma máquina de tempo;
• uma abordagem de consulta nova e poderosa;
• uma nova abordagem de esquema;
• caracteristicas de cache e expansão.

Atualmente o DynamoDB, Riak, Couchbase, Infinispan suportam o SQL como o mecanismo de armazenamento subjacente. Permitindo também que se misture e consulte diferentes bancos de dados ao mesmo tempo. Muitos veteranos ficaram surpresos que tal mudança de paradigma radical seja possível. Felizmente é.

Resumo

Para concluir, vamos abordar três pontos:

1. Alguns artigos novos do Eric Brewer sobre o teorema CAP deveriam ter vindo há vários anos. Neste artigo, Brewer afirma que "2 de 3" são ilusórios, explicando os motivos, porque o mundo é mais complicado do que um simples CP/AP, isto é, uma escolha ACID/BASE. No entanto, milhares de palestras e artigos continuavam elogiando o teorema CAP, sem qualquer resenha crítica por anos. Michael Stonebraker foi o mais firme a censurar o movimento NoSQL (e o espaço NoSQL lhe deve muito), apontando para esses problemas há alguns anos! Infelizmente, muitos não estão ouvindo. Mas agora que Eric Brewer atualizou seu teorema, o tempo de simples instruções CAP definitivamente acabou. Por favor, esteja bem na frente em apontar as verdadeiras e diversas implicações do CAP.
2. Como se sabe, as fraquezas dos bancos de dados relacionais clássicos têm levado empresas a experimentarem o NoSQL. Mas era apenas uma questão de tempo para o império contra-atacar. Sob o termo "NewSQL" podemos ver um série de novos motores (como database.com, VoltDB, GenieDB, etc - ver figura 2), melhorar as soluções clássicas, sharding e soluções de cloud computing. Graças ao movimento NoSQL.
3. Mas, como muitos DBs tentam implementar cada característica, as fronteiras claras desaparecem.
4. A decisão por um banco de dados está ficando mais complicado do que nunca.
5. É necessário conhecer cerca de 50 casos de uso e 50 DBs, além de responder a pelo menos 50 perguntas. Os últimos foram reunidos pelo autor em mais de dois anos de consultoria em NoSQL e podem ser encontrados aqui: Selecione o banco de dados certo, Escolhendo entre NoSQL e NewSQL (ambos em inglês).
6. É senso comum que cada mudança de tecnologia − desde cliente-servidor e antes − está cerca de dez vezes mais caro para mudar. Por exemplo, a mudança de Mainframe para cliente-servidor, de cliente-servidor para SOA, de SOA para Web, de SGBDR para persistência híbrida, etc. E, como consequência, muitas empresas hesitam e relutam em adicionar NoSQL ao seu portfólio. Mas sabe-se também que os primeiros a adotar e que estão tentando tirar o melhor proveito de ambos os mundos e assim integram NoSQL ficarão rapidamente melhor posicionados para o futuro. Neste sentido, as soluções NoSQL chegaram para ficar e sempre serão áreas de avaliações vantajosas.

Sobre o autor

Prof. Dr. Stefan Edlich é professor acadêmico da universidade Beuth Hochschule de Tecnologia de Berlim. Escreveu mais de dez livros de TI para editoras como Apress, OReilly, Spektrum/Elsevier e outras. Atualmente dirige o NoSQL Archive, fez consultoria NoSQL, organiza conferências NoSQL, escreveu os dois primeiros livros NoSQL do mundo e é viciado em linguagem de programação Clojure.