Introdução ao NoSQL parte I

Seg, Mar 8, 2010

NoSQL

Os bancos de dados conhecidos como NoSQL (Not only SQL)  surgiram da necessidade de escalar bancos de dados para o resolver os problemas das aplicações web que operam em larga escala. Segundo a definição da wikipedia :

NoSQL é um um termo genérico para uma classe definida de banco de dados não-relacionais que rompe uma longa história (ou império) de banco de dados relacionais com propriedades ACID. ”

Não podemos dizer que o NoSQL rompe o “império” dos bancos de dados relacionais. Os bancos de dados NoSQL servem para uma gama de problemas que nem sempre são os mesmos dos bancos de dados relacionais.

Muito tem se dito sobre as vantagens em termos de escala dos bancos de dados NoSQL em comparação aos bancos relacionais. Não é verdade que os RDBMS (relational database management system) não escalam. O fato é que eles não escalam facilmente. Vejamos um esquema básico de aplicação web  moderna:

01 205x300 Introdução ao NoSQL parte I

A medida que este sistema passa a receber um número maior de usuários começam a surgir nossos primeiros problemas de escalabilidade.  Temos então duas opções :

1) Aumentar o poder do nosso servidor, aumentando sua memória, processador e armazenamento. Este tipo de solução é chamada de Escalabilidade Vertical (scale up).

2) Aumentar o número de máquinas de servidores web.  Isto é chamado de Escalabilidade Horizontal (scale out). Como mostrado no esquema abaixo :

02 300x213 Introdução ao NoSQL parte I

Suponhamos que nossa aplicação continue crescendo bastante. Neste esquema acabaríamos chegando a um momento onde o banco seria o nosso maior gargalo uma vez que ele não conseguiria atender a todas as requisições em tempo hábil. Neste momento poderíamos apelar para a Escalabilidade Vertical e fazer um upgrade na máquina que está rodando nosso banco de dados. Mas esta abordagem é limitada pelo fato de que chegaríamos a um limite de capacidade com uma unica máquina ou chegariamos a um limite de orçamento para conseguir uma maquina extremamente poderosa. Assim nosso próximo passo mais lógico seria tentar escalar horizontalmente nosso banco, ou seja, colocar mais máquinas rodando o nosso banco:

04 300x139 Introdução ao NoSQL parte I

Agora que temos a missão de escalar nosso banco de dados através de múltiplas máquinas, vamos perceber que é bem mais complicado do que com os nossos servidores web.  Na maioria dos casos não podemos simplesmente ligar mais uma máquina rodando o banco e esperar que tudo funcione. Vamos precisar de uma série de configurações e alterações nas nossas aplicações para fazer tudo funcionar na nova arquitetura distribuída.

Os bancos de dados NoSQL vem para tornar este processo que muitas vezes é trabalhoso e complicado em um processo mais simples e robusto. Permitindo assim que os desenvolvedores se preocupem mais com suas aplicações e menos com manutenção. Esta facilidade de escala proporcionada por estas soluções tem sido um dos maiores motivos pelos quais os bancos NoSQL se espalharam rapidamente pelas  maiores aplicações web em funcionamento na atualidade.

Assim podemos dizer que tanto os bancos de dados relacionais quanto os não relacionais podem coexistir. Eles atendem em sua maioria a casos de usos diferentes como ilustrado na figura abaixo:

03 300x115 Introdução ao NoSQL parte I

No próximo post vamos estudar as principais características que diferenciam os múltiplos bancos de dados NoSQL e vamos agrupar as soluções existentes de acordo com estas características.

E você, acha que o NoSQL pode conviver com os bancos de dados relacionais ? Conte suas experiências escalando RDBMs !



, , ,

Por:

Que escreveu 39 posts em Escalabilidade.


Fale com o autor

  • http://herberthamaral.com/ Herberth Amaral

    Banco de dados NoSQL *tem* que conviver com bancos de dados relacionais. RDBMS ainda está aí pra quem tem que trabalhar com sistemas legados.

    Uma outra forma interessante de escalar bancos de dados relacionais é a desnormalização, principalmente para evitar JOINs e algumas funções agregadas.

    Excelente post. Parabéns!

  • http://devkico.itexto.com.br/ Henrique Lobo Weissmann (Kico)

    Achei o post muito bacana, mas ficou uma dúvida: como os bancos de dados NoSQL resolvem o problema da escalabilidade?

  • http://www.sanainside.com Diego Sana

    Percebeu a ironia no seu comentário, Herbert? JOIN e normalização são características marcantes no modelo relacional. Quando você chuta o balde dessa forma para conseguir escalar um RDBMS, significa que a rigor você não precisa mais de um RDBMS :) Esse pequeno paradoxo é comumente citado como motivação pelos desenvolvedores de bancos NOSQL e pelos que os adotam em suas apps.

  • fulvius

    Existem operações que um NoSQL db não consegue lidar muito bem. Ex.: uma transação de finalização de uma compra, onde envolve pagamento, baixa no estoque, etc… NoSQL é ótimo para operações massivas (como read), mas pela sua natureza não oferece ferramentas para lidar com operações que exigem consistencia, o que obriga levar esse controle para o nivel de programação.

  • http://pomoti.com/ Dirceu Pauka Júnior

    Eu acho que o que diferencia o “NoSQL” (escolhe ruim de nome na minha opinião) dos RDBMs não é a escalabilidade. Em muitos “NoSQL”s, montar um cluster não é tão simples. Dá (quase) o mesmo trabalho (http://gist.github.com/302894). Em outros não é nem possível montar cluster (só no master-slave…)

    O que vale é usar a ferramenta certa. Se a maioria (ou a parte mais pesada) da aplicação busca os dados somente pelo índice primário, vale a pena dar uma olhada no Tokyo. Se precisar ser mais rápido e/ou precisar de por exemplo um “incremental” consistente entre vários clientes, Redis. Alta escala? Cassandra/HBase/Voldemort… Tem medo de MapReduce? MySQL onde precisa e no item faz referencia à chave para a DB chave-valor… se o tipo de dado permitir você pode jogar fora coisas antigas do MySQL e continuar com os itens na DB chave-valor ^^

    Já falei que não acho legal o termo “NoSQL”… Vocês acham?

  • diogo moreira

    como os bancos de dados NoSQL resolvem o problema de escalabilidade, de concorrência e do paralelismo?

  • Pingback: Introdução ao NoSQL parte II | Escalabilidade

  • Pingback: No-SQL – MongoDB – Da introdução a utilização em alto nível em C# com NoRM. « FredZvt.WriteLines();

  • Pingback: No-SQL – MongoDB – From introduction to high level usage in C# with NoRM. « FredZvt.WriteLines();

  • Pingback: NoSQL, A evolução das bases de dados. | Coruja de TI

  • Pingback: Explorando o software por trás do Facebook, a maior rede social do mundo | Bit a Bit

  • Pingback: Dean Costa » Explorando o software por trás do Facebook, a maior rede social do mundo

  • Vickron

    Sempre achei que a normalização deveria ser uma decisão de análise. Alguém impôs a normalização por força-de-lei nos DBRMS’ o que já existia antes dos bancos de dados relacionais aparecerem, ou seja, gravar tudo em arquivos de dados não normalizados, não relacionais. Isso eu já fazia nos anos 70 com arquivos TXT, e se você observar bem, seja XML ou JSON, isso não passa de TXT… O fato é que chega a um ponto em que precisamos de consistência ACID em certos elementos, e não precisamos dela em outros, nos quais o mais importante, é o desempenho. Boa hora de não usar nada relacional ou nada em milhares de camadas OO sobrepostas que são lindas, mas simplesmente matam o desempenho… E o banco não tem que ser NO SQL e sim NOT ONLY SQL… daí a sigla… Não é para substituir o SQL apenas abrir mão dele em casos onde o desempenho seja imprescindível…

  • Vickron

    Sempre achei que a normalização deveria ser uma decisão de análise. Alguém impôs a normalização por força-de-lei nos DBRMS, agora inventam o que já existia antes dos bancos de dados relacionais aparecerem, ou seja, gravar tudo em arquivos de dados não normalizados, não relacionais. Isso eu já fazia nos anos 70 com arquivos TXT, e se você observar bem, seja XML ou JSON, isso não passa de TXT… O fato é que chega a um ponto em que precisamos de consistência ACID em certos elementos, e não precisamos dela em outros, nos quais o mais importante, é o desempenho. Boa hora de não usar nada relacional ou nada em milhares de camadas OO sobrepostas que são lindas, mas simplesmente matam o desempenho… E o banco não tem que ser NO SQL e sim NOT ONLY SQL… daí a sigla… Não é para substituir o SQL apenas abrir mão dele em casos onde o desempenho seja imprescindível…

  • Vickron

    Sempre achei que a normalização deveria ser uma decisão de análise. Alguém impôs a normalização por força-de-lei nos DBRMS, agora inventam o que já existia antes dos bancos de dados relacionais aparecerem, ou seja, gravar tudo em arquivos de dados não normalizados, não relacionais. Isso eu já fazia nos anos 70 com arquivos TXT, e se você observar bem, seja XML ou JSON, isso não passa de TXT… O fato é que chega a um ponto em que precisamos de consistência ACID em certos elementos, e não precisamos dela em outros, nos quais o mais importante, é o desempenho. Boa hora de não usar nada relacional ou nada em milhares de camadas OO sobrepostas que são lindas, mas simplesmente matam o desempenho… E o banco não tem que ser NO SQL e sim NOT ONLY SQL… daí a sigla… Não é para substituir o SQL apenas abrir mão dele em casos onde o desempenho seja imprescindível…

  • Pingback: Explorando o software por trás do Facebook, a maior rede social do mundo « Oneide Luiz Schneider

  • Marcaum54

    Muito bom cara, tirou minha dúvida, parabéns e continue assim…

  • Asdf

    kp´]

  • Danilo

    Muito bem escrito, parabéns.