NoSQL e a Persistência Poliglota
1. Um pouco de História
O termo Nosql parece ter surgido na década de 90 como nome de um sistema gerenciador de bancos de dados relacional baseado em shell unix desenvolvido por Carlos Strozzi, o Strozzi NoSQL. Esse banco de dados criava suas tabelas como arquivos de texto ASCII em que cada linha era uma tupla e cujos campos das tuplas eram separados por tabulações. O nome NoSQL se referia ao fato do gerenciador não utilizar SQL como linguagem de consulta.
As razões para essa decisão segundo o time de desenvolvimento liderado por Strozzi eram a complexidade dos sistemas SQL para projetos pequenos, portabilidade dos dados, limitação dos tamanhos de campos, colunas e arquivos, e por fim, a usabilidade limitada uma vez que a linguagem SQL requeria maior nível técnico dos usuários.
Mais tarde, em 11 de junho de 2009, Johan Oskarsson havia organizado uma conferência de tecnologia em São Francisco onde se apresentaria uma série de tecnologias novas de armazenamento como alternativa aos modelos SQL, inspiradas em tecnologias emergentes como o BigTable e o Dynamo. Conta-se que Oskarsson havia pedido uma sugestão de hashtags para anunciar a conferência no twitter, e um contato de nome Eric Evans sugeriu ‘NoSQL’.
O Termo NoSQL passou a referir-se a um conjunto de bancos de dados não relacionais, distribuídos e de código-fonte aberto, apresentados na conferência organizada por Johan Oskarsson. As tecnologias apresentadas foram Voldemort, Cassandra, Dynomite, Hbase, Hypertable, CouchDB e MongoDB.
Embora o acrónimo NoSQL tenha a partir de então se tornado um sucesso, este nunca favoreceu uma definição abrangente e consensual sobre o seu significado, destinando-se o termo como rótulo para o conjunto de tecnologias alternativas de armazenamento de dados que compartilhavam entre si características comuns como a não utilização estrita do padrão SQL, código-fonte aberto, possibilidade de execução em clusters de servidores, ausência de transações ACID e bancos de dados schemaless.
Comercialmente, talvez o principal fator para o desenvolvimento e adoção dessas tecnologias NoSql tenha sido o próprio contexto de desenvolvimento da web 2.0, quando os sites web se tornam verdadeiras aplicações com a possibilidade de interação rica por parte dos usuários, tal como as aplicações desktop. Neste cenário, requisitos de captura, coleta, armazenamento e tratamento de dados ganham novos desafios técnicos, principalmente ao que diz respeito o volume, a velocidade e a variabilidade dos dados produzidos tanto por usuários como pelas próprias aplicações.
2. O poder do banco de dado relacional
Ainda que os bancos de dados NoSQL tenham nos últimos anos ganhado adoção considerável, é bem provável que os bancos relacionais SQL se mantenham como padrão para a maioria dos projetos devido sua familiaridade de uso, estabilidade, recursos e suporte.
Acresce a isso algumas características que fazem desse tipo de banco a escolha certa para algumas aplicações sempre que estas demandarem:
SQL como linguagem padrão – tanto para definição como para manipulação de dados;
Mecanismo de transação de controle de concorrência;
Transações ACID – conjunto de operações relacionadas executadas como uma única operação garantindo ainda consistência dos dados, o isolamento com demais operações que possam estar ocorrendo em paralelo e a durabilidade das operações efetuadas. Esta característica é de fundamental importância para aplicações OLTP;
Cruzamento flexível de dados – indispensável para aplicações como as OLAP.
3. As fraquezas do banco de dado relacional
Os bancos de dados relacionais SQL não são nem poderiam ser a escolha correta para todo e qualquer aplicação que demande persistência de dados. Se algumas de suas características os tornam a escolha natural para uma infinidade de tipos diferentes de aplicações, por outro lado, algumas outras os tornam inadequados. Bancos de dados relacionais devem ser evitados sempre que os seguintes requisitos forem inflexíveis:
Os bancos deverão ser executados em um cluster de servidores de modo a terem suas capacidades para lidar com volumes maiores de informação ampliadas;
As aplicações precisam lidar massivamente com dados estruturados ou semi-estruturados;
Não deve haver incompatibilidade de impedância – ou seja, a maneira como os dados são representados logicamente e fisicamente devem ser os mesmos, de modo que isto não se torne um ônus ao programador, comprometendo sua produtividade.
4. Persistência poliglota
Recapitulamos um pouco da história evolutiva dos bancos de dados NoSQL bem como as características dos bancos de dados relacionais SQL clássicos que ainda os mantém como escolha adequado para uma infinidade de projetos novos. Embora um avanço considerável na adoção de bancos de dados NoSQL tenha ocorrido, isso não significa de maneira alguma que esta tecnologia vise ( ou possa ) substituir os bancos de dados relacionais. O Atual estágio de desenvolvimento das tecnologias de persistência, pelo contrário, é de um cenário mais rico, trazendo possibilidades novas e facilitando a resolução de problemas de maior complexidade.
Muitos dos projetos atuais exigem a capacidade de lidar com diferentes tipos de dados. Bancos de dados diferentes são construídos para lidar com tipo de dados diferentes, e esse fato elementar propícia a cultura da persistência poliglota.
Persistência poliglota é justamente a noção de que, para um determinado tipo de dado, existe uma escolha de modelo de banco mais adequado, de modo que diferentes tipos de modelo devem ser aplicados em conjunto, cabendo a cada um dos modelos escolhidos a tarefa de lidar com o tipo de requisito de persistência para o qual fora essencialmente projetado.
Para ilustrar o ponto acima, vejamos um diagrama simples (Figura 1) representando a camada de persistência de uma aplicação de comércio eletrônico.
Figura 1 - Persistência Poliglota aplicada ao e-commerce
Este cenário não é de todo incomum, mesmo nos dias de hoje: todos os requisitos de persistência supridos por um SGDB relacional. Num primeiro momento, entende-se que uma tal arquitetura possa suprir as necessidades de persistência de dados do negócio que ainda não são tão grande, dado que o negócio em si ainda se encontre em estágio inicial do seu desenvolvimento comercial. Igualmente, os requisitos de conhecimento técnico para a implementação rápida dos requisitos de negócio são menores, o que permite a equipe de desenvolvimento entregar implementações mais rapidamente.
Contudo, não é difícil imaginar as dificuldades que surgirão quando o negócio comércio eletrônico evoluir comercialmente, angariando uma base de usuários infinitamente maior. Nesse cenário futuro e provável, como essa camada de persistência poderia escalar de forma otimizada quando milhares ou até milhões de dados precisarem ser manipulados em segundos? Ainda: como implementar um novo requisito, digamos, um sistema de recomendação de novos produtos baseado em compras passadas dos usuários?
A estratégia da persistência poliglota instruiria os arquitetos da camada de persistência a repensarem a arquitetura conforme Figura 2.
Figura 2 - Arquitetura da Persistência Poliglota
Com a simples decisão de se escolher o banco adequado para lidar com o requisito especifico de persistência e de manipulação de dados, problemas de escala, eficiência e produtividade da equipe de desenvolvimento são resolvidos.
5. pontos-chave
Não há consenso sobre o significado do termo NoSQL de modo que este termo passa a ser normalmente utilizado para descrever um conjunto de bancos de dados que surgiram no contexto evolutivo da web 2.0 e que possuem as características de serem executáveis em cluster de máquinas servidoras, possuírem código-fonte aberto, não adotarem esquema fixo de dados, e de proporem formas alternativas para a garantia da consistência;
Embora os bancos de dados NoSQL tenham ganhado considerável adoção nos últimos anos, é provável que os bancos relacionais SQL ainda se mantenham por muito tempo como escolha padrão para a maioria dos projetos;
Aplicações com exigências complexas de persistência e de manipulação de dados são melhor tratadas com a estratégia da persistência poliglota.
Nos próximos dias, daremos continuidade demonstrando cada uma destas tecnologias e como as organizações podem se beneficiar. Além disto, apresentaremos alguns estudos de caso de como estas tecnologias vem sendo aplicadas em indústrias de pequeno, médio e grande porte, trazendo benefícios reais a todos os envolvidos no processo.
Se você gostou do tema, não deixe de avaliar e compartilhar! Também deixe o seu comentário, para que possamos debatermos sobre estas tecnologias e suas aplicações!
Para receber mais artigos como este, inscreva-se na nossa newsletter de publicações. Basta preencher o formulário abaixo.
Sugira temas para discutirmos no nosso blog! Basta preencher o formulário abaixo!