Bancos de dados relacionais (RDBMS – Relational Database Management Systems) tem sido o principal modelo para a gestão de banco de dados durante as últimas décadas. Mas nos últimos anos, bancos de dados “NoSQL” vem ganhando proeminência como um modelo alternativo de gestão de banco de dados. Vamos discutir neste artigo, por que essa evolução na gestão de banco de dados está acontecendo e quando utilizar uma solução ou outra.

SQL (Structured Query Language) é a linguagem de programação padrão usada para se comunicar com um banco de dados relacional. Você pode usar SQL para operações em banco de dados, como consulta de dados, atualização ou mesmo remoção dos dados. Um servidor RDBMS consiste em um banco de dados relacional, que dispõe de um conjunto de tabelas que contêm dados com categorias ou colunas predefinidas. Ele contém dados estruturados, como nomes, endereços de e-mail, dados de vendas, contas a pagar, cadastro de clientes, etc… Um banco de dados relacional combina dados usando características comuns encontradas no conjunto de dados e o grupo resultante é denominado como Schema.

Durante várias décadas, os RDBMS atenderam o seu propósito e ainda o fazem muito bem, mas com o surgimento do Big Data e esta imensa quantidade de dados de diferentes categorias, gerados em diferentes velocidades e volumes, novos modelos de gestão de dados começaram a surgir. Isto levou ao crescimento de soluções NoSQL, comumente referido como “Not Only SQL”. Com NoSQL, dados não estruturados podem ser armazenados em vários nós de processamento e não requerem schemas fixos, geralmente evitam operações de join e, normalmente, funcionam bem com escalonamento horizontal.

Bancos de Dados Relacionais

Bancos de dados relacionais representam e armazenam os dados em tabelas, organizadas em linhas e colunas. Eles são baseados em um ramo da teoria dos conjuntos algébricos conhecido como álgebra relacional.

Bancos de dados relacionais usam linguagem SQL, tornando-os uma boa escolha para aplicações que envolvem a gestão de várias operações. A estrutura de um banco de dados relacional permite unir informações de diferentes tabelas através do uso de chaves estrangeiras (ou índices), que são usados para identificar exclusivamente qualquer peça atômica de dados dentro dessas tabelas. As tabelas se conectam através de chaves estrangeiras, de modo a criar uma ligação entre as suas peças de dados.

Se você tiver aplicações que lidam com uma grande quantidade de consultas complexas, transações de banco de dados e análise de dados de rotina, você provavelmente vai preferir utilizar um banco de dados relacional. E se a sua aplicação tem como foco principal a execução de muitas transações, é importante que essas transações sejam processadas de forma confiável. Este é o lugar onde ACID (o conjunto de propriedades que garante que as transações de banco de dados sejam processados de forma confiável) realmente importa e onde a integridade referencial entra em jogo.

A integridade referencial é o conceito em que várias tabelas de banco de dados compartilham uma relação com base nos dados armazenados nas tabelas e essa relação deve ser coerente. Isso geralmente é imposto com ações de adição, exclusão e atualização em cascata.

Quando usar RDBMS ou NoSQL?

Principais Bancos de Dados Relacionais

E o que motivou o surgimento do NoSQL?

NoSQL abrange uma grande variedade de diferentes tecnologias de banco de dados que foram criados em resposta às demandas apresentadas na construção de aplicações modernas, tais como:

  • Cada vez mais, os desenvolvedores trabalham com aplicativos que criam grandes volumes de novos tipos de dados e que mudam rapidamente, sejam estes dados estruturados, semiestruturados ou não estruturados.
  • Em um passado não muito distante, o ciclo de desenvolvimento de aplicações era de 12 a 18 meses. Agora pequenas equipes trabalham com metodologias ágeis de desenvolvimento, interagindo de forma rápida e liberando código a cada semana ou duas, algumas até mesmo várias vezes por dia.
  • Aplicações que antes serviam a um público finito agora são entregues como serviços que devem estar sempre online, acessíveis a partir de vários dispositivos diferentes e disponíveis em todo o mundo para milhões de usuários.
  • As organizações estão redimensionando suas arquiteturas e cada vez mais utilizam software de código aberto, servidores commodities (como no caso do Hadoop) e computação em nuvem, em vez de grandes servidores monolíticos e infraestrutura de armazenamento.

Ou seja, estamos vivenciando uma transformação na forma como se coleta, armazena e analisa os dados e esta transformação, requer novas tecnologias. Exatamente daí surgiram as necessidades que tem levado ao crescimento de bancos de dados NoSQL.

Mas o que são Bancos de Dados NoSQL?

NoSQL é uma tecnologia de banco de dados projetada para suportar os requisitos de aplicações em nuvem e arquitetado para superar a escala, desempenho, modelo de dados e as limitações de bancos de dados relacionais (RDBMS).

Bancos de Dados NoSQL (Not Only SQL) foram concebidos para armazenar, distribuir e acessar dados usando métodos que diferem de bancos de dados relacionais (RDBMS). A tecnologia NoSQL foi originalmente criada e usada por líderes da Internet como Facebook, Google, Amazon, e outros que necessitavam de sistemas de gerenciamento de banco de dados que pudessem escrever e ler dados em qualquer lugar no mundo e que garantissem desempenho a grandes conjuntos de dados e milhões de usuários.

Hoje, quase todas as empresas e organizações possuem aplicativos em nuvem que personalizam a experiência do cliente com o seu negócio e soluções NoSQL podem ser a tecnologia de banco de dados escolhida para alimentar esses sistemas.

Quando utilizar RDBMS ou NoSQL?

Principais Bancos de Dados NoSQL

Neste endereço você encontra uma lista completa de todos os Bancos de Dados NoSQL disponíveis atualmente: http://nosql-database.org.

A Oracle, líder mundial em bancos de dados relacionais, de olho neste mercado, lançou recentemente a sua versão de banco de dados NoSQL. Clique aqui para acessar a página do Oracle NoSQL Database.

E qual solução de bancos de dados utilizar?

A primeira consideração que precisa ser feita ao selecionar um banco de dados são as características dos dados que serão armazenados. Se os dados têm uma estrutura tabular simples, como uma folha de contabilidade, o modelo relacional será o mais adequado.

Porém, quando falamos de dados geo-espaciais, peças de engenharia, modelagem molecular ou Big Data, estamos falando de dados com estrutura muito mais complexa. Eles podem ter vários níveis de aninhamento e o modelo completo de dados pode ser complicado. Esses dados, no passado, foram modelados em tabelas relacionais, mas não se encaixam perfeitamente em uma estrutura de linha-coluna bidimensional. Nestes casos, deve-se considerar bancos de dados NoSQL como uma opção. Aninhamento e hierarquias multi-nível são muito facilmente representadas no formato JavaScript Object Notation (JSON) usado por alguns produtos NoSQL, por exemplo.

Antes de decidir qual a melhor solução para os seus dados, algumas perguntas precisam ser respondidas:

Apenas “Data” ou “Big Data”?

Enquanto bancos de dados relacionais podem armazenar e manipular dados de forma confiável, a maior proposta para NoSQL vem na forma do que chamamos de Big Data – enormes quantidades de dados semiestruturados ou não-estruturados gerados por máquinas ou pela sociedade todos os dias. A abordagem NoSQL, sem esquema de gerenciamento de dados, pode ser potencialmente a única maneira de entender como capturar, pesquisar, analisar e visualizar Big Data.

Tabelas ou Coleções?

A principal diferença entre bancos de dados relacionais e não-relacionais é a forma como os dados são armazenados. Dados relacionais são tabulares por natureza – e, portanto, armazenados em tabelas com linhas e colunas. As tabelas podem ser relacionadas entre si e cooperam no armazenamento de dados, bem como na fácil recuperação dos dados. Os dados não-relacionais, por outro lado, não são destinados apenas a coleta em tabelas de linhas e colunas, mas sim agrupados em blocos. Os dados não-relacionais são muitas vezes armazenados como Coleções, como em documentos, pares chave-valor ou gráficos. Portanto, a natureza dos seus dados é um dos principais indicadores para qual abordagem funciona melhor para o armazenamento e recuperação de dados.

Schemas Pré-definidos ou Schemas Dinâmicos?

Os dados relacionais são muitas vezes referidos como dados estruturados, porque as tabelas têm um esquema pré-definido para descrever os dados. Isso dá a modelagem de dados suma importância e exige as atitudes “Faça certo da primeira vez”. Enquanto um esquema pré-definido oferece confiabilidade e estabilidade, as mudanças a um esquema em uma tabela com dados pré-existentes é bem mais difícil. Os dados não-relacionais, por outro lado, são organizados em esquemas dinâmicos e são muitas vezes referidos como dados não-estruturados. Os dados não-relacionais podem facilmente acomodar mudanças no tipo / estrutura de dados devido ao seu formato com esquemas dinâmicos.

ACID ou CAP?

Bancos de dados relacionais são muito famosos por manter a integridade através do que é chamado de ACID (Atomic | Consistence | Isolated | Durable), propriedades encontradas em todos os bancos de dados relacionais. O objetivo é apoiar as operações indivisíveis isoladas cujas alterações são persistentes e deixar os dados em um estado consistente. Bancos de dados NoSQL, por outro lado, fazem com que você tenha que escolher entre quaisquer duas prioridades do CAP (Consistency | Availability | Partition Tolerance), uma vez que todos os três são difíceis de se conseguir em um sistema baseado em nó distribuído.

Queries Estruturadas ou Não-estruturadas?

Bancos de dados relacionais manipulam dados através de linguagem SQL. SQL é incrivelmente poderosa para apoiar operações de CRUD (Create, Read, Update, Delete) e é um padrão no mercado de banco de dados relacionais. Bancos de dados não relacionais manipulam dados em blocos (como documentos) e usam algo chamado Unstructured Query Language (UnQL), que não é padrão e pode variar entre os provedores de bancos de dados NoSQL. O conceito chave primária em uma tabela relacional é equivalente ao conceito de ID de documento em um armazenamento não-relacional. Bancos de dados relacionais empregam optimizações pré-definidas, como definições de índice de coluna para ajudar a acelerar as operações de consulta, enquanto bancos de dados NoSQL desfrutam de padrões mais simples e restritos de acesso aos dados.

Normalização ou Custo de Armazenamento?

Armazenamento de dados em bancos de dados relacionais aponta para maior normalização – quebrando os dados em tabelas lógicas menores (relacionadas) para evitar a duplicação e obter melhor utilização do espaço. Embora a normalização dos dados seja fundamental, ela muitas vezes adiciona um pouco de complexidade, especialmente em matéria de gestão de dados onde uma única operação pode ter que abranger inúmeras tabelas relacionadas. Além disso, a normalização visava economizar o armazenamento de banco de dados, o que em grande parte é irrelevante no mundo de hoje, onde o custo de armazenagem (espaço em disco) é trivial. Os dados não-relacionais, por outro lado, possuem armazenamento em coleções planas, onde os dados podem muitas vezes ser duplicados. Um único bloco de dados raramente é dissociado, mas sim armazenado como uma entidade, permitindo assim acesso mais fácil de leitura/escrita a uma entidade única.

Conclusão

RDBMS e NoSQL são excelentes soluções em gerenciamento de dados e ambos são usados para manter o armazenamento e recuperação de dados de forma otimizada. É difícil dizer qual tecnologia é melhor e como sempre, o que vai determinar a sua escolha é o tipo de dados que você tem em mãos e a natureza da sua aplicação. Mas na tabela abaixo você encontra algumas dicas gerais, para ajuda-lo na escolha:

RDBMSxNoSQL

Espero que agora esteja mais claro quando utilizar uma tecnologia ou outra. Mas lembre-se, seus dados que vão determinar sua escolha. Até o próximo post.

Tiago Pereira

 

Referências:

Gerenciamento de Dados com MongoDB

Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design