Vejo muita confusão sobre o lugar e propósito das muitas novas soluções de base de dados (“bases de dados NoSQL”) em comparação com as soluções de base de dados relacionais que existem há muitos anos. Então deixe-me tentar explicar as diferenças e os melhores casos de uso para cada um.
Primeiro permite esclarecer essas soluções de banco de dados em dois grupos:
1) Bancos de dados relacionais, que também podem ser chamados de sistemas de gerenciamento de bancos de dados relacionais (RDBMS) ou bancos de dados SQL. Os mais populares são o Microsoft SQL Server, Oracle Database, MySQL, e IBM DB2. Estes RDBMS são utilizados principalmente em grandes cenários empresariais, com exceção do MySQL, que é utilizado principalmente para armazenar dados para aplicações web, normalmente como parte da popular pilha LAMP (Linux, Apache, MySQL, PHP/ Python/ Perl).
2) Bancos de dados não-relacionais, também chamados de bancos de dados NoSQL, os mais populares são MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis, e Neo4j. Estes bancos de dados são normalmente agrupados em quatro categorias: Lojas de valores-chave, Lojas de gráficos, Lojas de colunas e Lojas de documentos (ver Tipos de bancos de dados NoSQL).
Todos os bancos de dados relacionais podem ser usados para gerenciar aplicações orientadas a transações (OLTP), e a maioria dos bancos de dados não relacionais que estão nas categorias Lojas de documentos e Lojas de colunas também podem ser usadas para OLTP, aumentando a confusão. Os bancos de dados OLTP podem ser considerados como bancos de dados “operacionais”, caracterizados por transações freqüentes e curtas que incluem atualizações e que tocam uma pequena quantidade de dados e onde a simultaneidade de milhares de transações é muito importante (exemplos incluindo aplicações bancárias e reservas on-line). A integridade dos dados é muito importante, pelo que suportam transacções ACID (Atomicidade, Consistência, Isolamento, Durabilidade). Isto é oposto aos data warehouses, que são considerados bases de dados “analíticos”, caracterizados por longas e complexas consultas que tocam uma grande quantidade de dados e requerem muitos recursos. As actualizações são pouco frequentes. Um exemplo é a análise das vendas do último ano.
Bases de dados relacionais geralmente trabalham com dados estruturados, enquanto que as bases de dados não-relacionais geralmente trabalham com dados semi-estruturados (ou seja, XML, JSON).
Vejamos cada grupo com mais detalhes:
Bases de dados relacionais
Uma base de dados relacional é organizada com base no modelo relacional de dados, como proposto por E.F. Codd em 1970. Este modelo organiza os dados em uma ou mais tabelas (ou “relações”) de linhas e colunas, com uma chave única para cada linha. Geralmente, cada tipo de entidade descrita em uma base de dados tem sua própria tabela com as linhas representando instâncias desse tipo de entidade e as colunas representando os valores atribuídos a essa instância. Como cada linha em uma tabela tem sua própria chave única, as linhas em uma tabela podem ser ligadas a linhas em outras tabelas armazenando a chave única da linha à qual ela deve estar ligada (onde essa chave única é conhecida como uma “chave estrangeira”). O Codd mostrou que relacionamentos de dados de complexidade arbitrária podem ser representados usando este simples conjunto de conceitos.
Virtualmente todos os sistemas de bancos de dados relacionais usam SQL (Structured Query Language) como a linguagem para consulta e manutenção do banco de dados.
As razões para o domínio de bancos de dados relacionais são: simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibilidade no gerenciamento de dados genéricos.
Mas para oferecer tudo isso, bancos de dados relacionais têm que ser incrivelmente complexos internamente. Por exemplo, uma instrução SELECT relativamente simples poderia ter dezenas de potenciais caminhos de execução de consultas, que um otimizador de consultas avaliaria em tempo de execução. Tudo isso é escondido para os usuários, mas sob a capa, o RDBMS determina o melhor “plano de execução” para responder às solicitações usando coisas como algoritmos baseados em custos.
Para grandes bancos de dados, especialmente os usados para aplicações web, a principal preocupação é a escalabilidade. À medida que mais e mais aplicações são criadas em ambientes que têm grandes cargas de trabalho (ou seja, a Amazon), seus requisitos de escalabilidade podem mudar muito rapidamente e crescer muito grande. As bases de dados relacionais escalam bem, mas normalmente só quando essa escalabilidade acontece em um único servidor (“scale-up”). Quando a capacidade desse único servidor é atingida, você precisa “escalar” e distribuir essa carga por vários servidores, passando para a chamada computação distribuída. Isto é quando a complexidade das bases de dados relacionais começa a causar problemas com o seu potencial de escalonamento. Se você tentar escalar para centenas ou milhares de servidores, as complexidades se tornam esmagadoras. As características que tornam os bancos de dados relacionais tão atraentes são as mesmas que também reduzem drasticamente sua viabilidade como plataformas para grandes sistemas distribuídos.
Bases de dados não-relacionais
Um banco de dados NoSQL fornece um mecanismo de armazenamento e recuperação de dados que é modelado em outros meios que não as relações tabulares utilizadas em bancos de dados relacionais.
Motivações para esta abordagem incluem:
- Simplicidade de design. Não ter que lidar com o “descompasso de impedância” entre a abordagem orientada a objetos para escrever aplicações e as tabelas e linhas baseadas em esquemas de uma base de dados relacional. Por exemplo, armazenar todas as informações de pedidos de clientes em um documento ao invés de ter que juntar muitas tabelas, resultando em menos código para escrever, depurar e manter
- Melhor escala “horizontal” para clusters de máquinas, o que resolve o problema quando o número de usuários simultâneos dispara para aplicações que são acessíveis via web e dispositivos móveis. O uso de documentos facilita muito o escalonamento, pois toda a informação para esse pedido do cliente está contida em um único lugar, ao invés de estar espalhada em várias tabelas. As bases de dados NoSQL espalham automaticamente os dados pelos servidores sem exigir alterações na aplicação (auto-sharding), o que significa que nativa e automaticamente espalham os dados por um número arbitrário de servidores, sem exigir que a aplicação esteja sequer ciente da composição do pool de servidores. A carga de dados e consultas é automaticamente balanceada entre servidores, e quando um servidor é desligado, pode ser substituída de forma rápida e transparente sem interrupção da aplicação
- Controle mais fino sobre a disponibilidade. Servidores podem ser adicionados ou removidos sem tempo de inatividade da aplicação. A maioria dos bancos de dados NoSQL suporta replicação de dados, armazenando múltiplas cópias de dados através do cluster ou mesmo através de centros de dados, para garantir alta disponibilidade e recuperação de desastres
- Para capturar facilmente todos os tipos de dados “Grandes Dados” que incluem dados não estruturados e semi-estruturados. Permitir uma base de dados flexível que possa acomodar fácil e rapidamente qualquer novo tipo de dados e que não seja perturbada por alterações na estrutura do conteúdo. Isto porque a base de dados de documentos não tem esquema, permitindo adicionar livremente campos aos documentos JSON sem ter de definir alterações (esquema sobre esquema em vez de esquema sobre esquema). O usuário pode ter documentos com um número de campos diferente de outros documentos. Por exemplo, um registro de paciente que pode ou não conter campos que listam alergias
- Velocidade. As estruturas de dados utilizadas pelos bancos de dados NoSQL (ou seja, documentos JSON) diferem daquelas utilizadas por padrão em bancos de dados relacionais, tornando muitas operações mais rápidas no NoSQL do que bancos de dados relacionais devido à não necessidade de juntar tabelas (ao custo do aumento do espaço de armazenamento devido à duplicação de dados – mas o espaço de armazenamento é tão barato hoje em dia isso normalmente não é um problema). Na verdade, a maioria das bases de dados NoSQL nem sequer suporta junções
- Custo. Os bancos de dados NoSQL geralmente usam clusters de servidores de commodity baratos, enquanto os RDBMS tendem a depender de servidores proprietários e sistemas de armazenamento caros. Além disso, as licenças para sistemas RDBMS podem ser bastante caras enquanto muitos bancos de dados NoSQL são de código aberto e, portanto, gratuitos
A adequação particular de um determinado banco de dados NoSQL depende do problema que ele deve resolver.
As bases de dados NoSQL são cada vez mais utilizadas em grandes dados e aplicações web em tempo real. Eles tornaram-se populares com a introdução da web, quando os bancos de dados passaram de um máximo de algumas centenas de usuários em uma aplicação interna da empresa para milhares ou milhões de usuários em uma aplicação web. Os sistemas NoSQL também são chamados de “Não apenas SQL” para enfatizar que eles também podem suportar linguagens de consulta do tipo SQL.
Muitas lojas NoSQL comprometem a consistência (no sentido do teorema CAP) em favor da disponibilidade e tolerância a partições. Algumas razões que bloqueiam a adoção de lojas NoSQL incluem o uso de linguagens de consulta de baixo nível, a falta de interfaces padronizadas, e enormes investimentos em SQL existentes. Além disso, a maioria das lojas NoSQL não possuem verdadeiras transações ACID ou só suportam transações em certas circunstâncias e em certos níveis (por exemplo, nível de documento). Finalmente, RDBMS’s são normalmente muito mais simples de usar já que possuem GUI’s onde muitas soluções NoSQL utilizam uma interface de linha de comando.
Comparando as duas
Uma das limitações mais severas das bases de dados relacionais é que cada item só pode conter um atributo. Se utilizarmos um exemplo de banco, cada aspecto do relacionamento de um cliente com um banco é armazenado como itens de linha separados em tabelas separadas. Assim, os detalhes mestre do cliente estão em uma tabela, os detalhes da conta estão em outra tabela, os detalhes do empréstimo em outra, os investimentos em uma tabela diferente, e assim por diante. Todas essas tabelas estão ligadas umas às outras através do uso de relações como chaves primárias e chaves estrangeiras.
Bases de dados não-relacionais, especificamente as lojas de valores-chave ou pares de valores-chave de uma base de dados, são radicalmente diferentes deste modelo. Os pares de chaves de valores permitem armazenar vários itens relacionados em uma “linha” de dados na mesma tabela. Nós colocamos a palavra “linha” entre aspas porque uma linha aqui não é realmente a mesma coisa que a linha de uma tabela relacional. Por exemplo, em uma tabela não relacional para o mesmo banco, cada linha conteria os detalhes do cliente, bem como os detalhes de sua conta, empréstimo e investimento. Todos os dados relacionados a um cliente seriam convenientemente armazenados juntos como um registro.
Este parece ser um método obviamente superior de armazenamento de dados, mas tem um grande inconveniente: armazéns de valores-chave, ao contrário dos bancos de dados relacionais, não podem impor relações entre os itens de dados. Por exemplo, na nossa base de dados de valores-chave, os detalhes do cliente (nome, segurança social, endereço, número da conta, número de processamento do empréstimo, etc.) seriam todos armazenados como um único registo de dados (em vez de serem armazenados em várias tabelas, como no modelo relacional). As transações do cliente (retiradas de conta, depósitos em conta, reembolsos de empréstimos, encargos bancários, etc.) também seriam armazenadas como outro único registro de dados.
No modelo relacional, há um método embutido e infalível de garantir e reforçar a lógica e as regras de negócios na camada de banco de dados, por exemplo, que uma retirada seja cobrada na conta bancária correta, através de chaves primárias e chaves estrangeiras. Nas lojas de chaves de valor, esta responsabilidade recai diretamente sobre a lógica da aplicação e muitas pessoas se sentem muito desconfortáveis, deixando esta responsabilidade crucial apenas para a aplicação. Esta é uma razão pela qual os bancos de dados relacionais continuarão a ser utilizados.
No entanto, quando se trata de aplicações baseadas na web que utilizam bancos de dados, o aspecto de reforçar rigorosamente a lógica de negócios muitas vezes não é uma prioridade máxima. A maior prioridade é a capacidade de atender a um grande número de solicitações de usuários, que normalmente são consultas apenas de leitura. Por exemplo, em um site como o eBay, a maioria dos usuários simplesmente navega e olha através de itens postados (operações somente leitura). Apenas uma fração desses usuários realmente coloca ofertas ou reserva os itens (operações de leitura-escrita). E lembre-se, estamos falando de milhões, às vezes bilhões, de page views por dia. Os administradores do site eBay estão mais interessados em um tempo de resposta rápido para garantir um carregamento de página mais rápido para os usuários do site, ao invés das prioridades tradicionais de fazer cumprir as regras de negócios ou garantir um equilíbrio entre leitura e escrita.
Bases de dados de modelos relacionais podem ser ajustadas e configuradas para executar operações de grande escala somente leitura através de data warehousing, e assim potencialmente servir uma grande quantidade de usuários que estão consultando uma grande quantidade de dados, especialmente quando usando arquiteturas MPP relacionais como Analytics Platform System, Teradata, Oracle Exadata, ou IBM Netezza, que todos suportam escalonamento. Como mencionado anteriormente, os data warehouses são distintos dos bancos de dados típicos, pois são utilizados para análises mais complexas de dados. Isto difere do banco de dados transacional (OLTP), cujo principal uso é suportar sistemas operacionais e oferecer relatórios diários em pequena escala.
No entanto, o verdadeiro desafio é a falta de escalabilidade do modelo relacional ao lidar com aplicações OLTP, ou qualquer solução com muitas escritas individuais, que é o domínio das arquiteturas SMP relacionais. É aqui que os modelos não relacionais podem realmente brilhar. Eles podem facilmente distribuir suas cargas de dados por dezenas, centenas e em casos extremos (pense na pesquisa do Google) até mesmo milhares de servidores. Com cada servidor lidando apenas com uma pequena porcentagem do total de solicitações dos usuários, o tempo de resposta é muito bom para cada usuário individual. Embora este modelo de computação distribuída possa ser construído para bases de dados relacionais, é uma verdadeira dor de cabeça para implementar, especialmente quando há muitas escritas (ou seja, OLTP), requerendo técnicas como o sharding, que normalmente requer uma codificação significativa fora da lógica de negócios da aplicação. Isto porque o modelo relacional insiste na integridade dos dados em todos os níveis, que devem ser mantidos, mesmo quando os dados são acessados e modificados por vários servidores diferentes. Esta é a razão para o modelo não relacional como a arquitetura de escolha para aplicações web, tais como computação em nuvem e redes sociais.
Então, em resumo, RDBMS’s não sofrem de escalonamento horizontal para altas cargas de transações (milhões de textos lidos), enquanto os bancos de dados NoSQL resolvem altas cargas de transações, mas ao custo da integridade dos dados e joinins.
Calcando em mente muitas soluções irão utilizar uma combinação de bancos de dados relacionais e não-relacionais (veja O que é a Persistência Poliglota?).
Tenham também em mente que você pode não precisar da performance de um banco de dados não-relacional e, em vez disso, basta apenas armazenar arquivos no HDFS e usar o Apache Hive (Apache Hive é uma infra-estrutura de data warehouse construída sobre o Hadoop para fornecer resumo de dados, consulta e análise que ele fornece através de uma linguagem SQL chamada HiveQL).
E para terminar em uma nota que acrescenta confusão, temos uma outra categoria formando chamada NewSQL: NewSQL é uma classe de RDBMS modernos que procuram fornecer o mesmo desempenho escalável dos sistemas NoSQL para cargas de trabalho de leitura-escrita OLTP enquanto ainda mantém as garantias ACID de um sistema de base de dados relacional tradicional. As desvantagens são que eles não são para consultas ao estilo OLAP, e são inadequados para bancos de dados acima de alguns terabytes. Exemplos incluem VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix, e Altibase.
Uma imagem mostrando as categorias em que muitos dos produtos se encaixam:
Um excelente gráfico que mostra como todas as tecnologias se encaixam na nuvem Azure é de Understanding NoSQL on Microsoft Azure:
A linha de fundo para usar uma solução NoSQL é se você tem uma aplicação OLTP que tem milhares de usuários e tem uma base de dados muito grande que requer uma solução escalonável e/ou está usando dados JSON, em particular se esses dados JSON têm várias estruturas. Você também obtém o benefício da alta disponibilidade, já que as soluções NoSQL armazenam múltiplas cópias dos dados. Apenas tenha em mente que para performance você pode sacrificar a consistência dos dados, assim como a habilidade de juntar dados, usar SQL, e fazer rápidas atualizações em massa.
Mais informações:
MySQL vs MongoDB
MySQL vs. MongoDB: Olhando para Bancos de Dados Relacionais e Não Relacionais
10 coisas que você deve saber sobre bancos de dados NoSQL
Introdução a Bancos de Dados
Diferença entre SQL e NoSQL : Comparação
Diferença entreSQL e NoSQL Explicada com poucos Exemplos DB
NoSQL, NewSQL, ou RDBMS: Como Escolher
NewSQL – RDBMS em Steroids
NoSQL vs. Bancos de Dados NewSQL Escolha a Ferramenta Certa para o Trabalho Certo
SQL vs. NoSQL: você quer ter um armazenamento relacional por padrão
Oracle Defende DBs Relacionais Contra Concorrentes do NoSQL
Entendendo NoSQL no Microsoft Azure
Conheça a Vanguarda de Novos Bancos de Dados Relacionais
Para SQL ou NoSQL? Essa é a questão do banco de dados
CAP Theorem: Revisitado
O que é realmente novo com o NewSQL?
MongoDB vs MySQL: Um Estudo Comparativo sobre Bases de Dados
Características e Diferenças de Bases de Dados doSQL e NoSQL