SQL X NOSQL Charles Fortes 16 de Maio de 2012 @CharlesFortes
Dec 04, 2014
SQL X NOSQL
Charles Fortes16 de Maio de 2012
@CharlesFortes
http://tinyurl.com/infotechdia16Avaliação da Palestra
@CharlesFortes
Persistência
Logo após superar as dificuldades do cartão perfurado, o homem teve outro grande desafio a sua frente!
Poder desligar o computador após horas de processando uma informação sem perder seus preciosos 300 Bytes de informação já processadas.
Persistir os dados nada mais é do que guardar a informação
em um local não volátil ao qual possa ser recuperada posteriormente.
Por exemplo, gravar os dados em um cartão perfurado, disquete (uma espécie de idade das trevas
da persistencia), HD, ou FlashStorage
Com o aumento do volume de dados, veio a necessidade de organizar melhor a
informação salva em benefício da velocidade de recuperação.
Imagine se o Facebook guardasse os dados em um TXT e todo vez que você entrasse para pentelhar a vida dos outros, ele tivesse de percorrer o arquivo - com alguns pentabytes de tamanho - para encontrar todos os
dados que devem lhe ser exibidos.
A conclusão desta necessidade foi o aparecimento dos bancos de dados.
Banco de dados relacional
Hoje quando pensamos em banco de dados, sempre nos
vem em mente os bancos de dados relacionais, como o SQLServer, Oracle, MySQL, Postgree, MSAccess (há! #euri)
Apesar de não ser o único modelo de banco de
dados possível, o modelo relacional é considerado o mais maduro.
"Os Bancos de Dados Relacionais foram desenvolvidos para prover acesso facilitado aos dados, possibilitando que os usuários utilizassem uma grande variedade de abordagens no tratamento das informações"
O banco de dados relacional é composto a grosso modo de Relações e Relacionamentos.
Relações (banco de dados relacional) dizem respeito as relações entre os domínio dos dados no sentido matemático (cada linha da
tabela é um elemento do conjunto relação).
Relacionamentos dizem respeito a como um registro está relacionado a outro registro de outro domínio (Ex.: Um fabricante possui um ou mais produtos)
Este é modelo que chamamos de Entidade Relacionamento (ou Entidade Relacional dependendo do autor)
Para acessar os dados e recuperar as informações da base, em uma
das várias abordagens que este modelo nos permitem,
usamos comandos em uma linguagem de scripts chamada SQL
Com o advento dos bancos de dados relacionais, somados aos discos de armazenamento realmente não voláteis (que exclui os disquetes e os HD's
Western Caviar da década de 90), o mundo estava em paz...
...até que um dia uns garotos resolveram que iam catalogar todas as páginas de todos os sites do mundo para que qualquer
um pudesse pesquisar e encontrar o que quiser...
...o que não seria um problema não fosse a segunda ideia...
...retornar o resultado por ordem de relevância para o usuário, mesmo que ele digite errado, e em menos de 1 segundo
nos 1.000 primeiras páginas isso foi moleza, mas depois da nº 1.000.000.000 isso começou a complicar um pouco...
NoSQL
A primeira vez registrada que o termpo NoSQL pode ser observada em 1998 quando Carlos Strozzi produziu um
trabalho falando sobre bancos de dados que não possuiam interface SQL.
O modelo surgiu diante do aumento crescente de dados não relacionais (fotos, logs, documentos, capturas de sensores, etc.)
O termo NoSQL significa "Not Only SQL". Chamando
atenção justamente para a existencia destes dados que não são facilmente recuperados ou manupulados pelas
instruções relacionais.
Em 2004 a google começou a trabalhar em um sistema de armazenamento de dados estruturados que fosse capaz de
armazenar seus petabytes de dados através de milhares de computadores, de forma que pudessem ser facilmente e
rapidamente recuperados e escalados.
Estes bilhões de dados crescentes são chamados de BigData
Em 2006 foi exibido ao mundo o Google BigTable, o primeiro grande sistema de armazenamento baseado em NoSQL colocado
em atividade para armazenagem e recuperação de BigData.
Quando usamos NoSQL?
Quando manipulamos grandes volumes de dados
Quando precisarmos de desempenho ao gravar grandes volumes de dados
Para ter rápido acesso a um dado "Chave/Valor"
Quando os dados não tem um esquema definido
Facilidade de Administração, Manutenção e Operação
Alta disponibilidade com balanceamento de carga
Poder usar o melhor modelo de dados para seu problema
Com a evolução do conceito, temos hoje 4 grandes modelos de bancos de dados NoSQL para atender
as mais variadas necessidades
Documento
Chave/Valor
Tabular
Gráfos
Chave/Valor
É o modelo mais simples, baseia-se em uma "tabela hash", onde cada chave é unica. Este
modelo é muito prático para se armazenar log por exemplo.
Documento
São muito similares ao modelo Chave/Valor, sendo um próximo nível de complexidade do modelo, armazenando coleções de chave/valor, permitindo valores aninhados associados a cada chave. São muito usados na Web e para a criação de CRUD
Tabular
Foram criadas para armazenar e para processar grandes quantidades de dados distribuídos em muitas máquinas.
As chaves apontam para múltiplas colunas
Gráfos
Um sistema de armazenamento baseado em relacionamento entre os nós que possuem flexibilidade de formato. Ideal para uso em redes sociais e outros problemas de grafos.
Persistência poliglota
Um SGBD convencional tem sua zona de conforto de escalabilidade muito aquem dos bancos de dados NoSQL tipicos, porém os dados estruturados, a maturidade do modelo e a consistencia da informação são ainda diferenciais
Aplicações complexas tendem a ter diversas diferentes caracteristicas de dados. Adaptando o modelo de Fowler, podemos ver que junção dos diferentes modelos de armazenamento de dados pode ser usado para benefício da aplicação.
• Documentoo RavenDBo CouchDBo MongoDBo MarkLogic Servero BaseXo eXist
• Chave/Valor (Key/Value)o Memcachedbo Project Voldemorto Rediso SimpleDBo Hbase
• Tabularo Cassandrao Hypertable
• Gráfoso Neo4jo DEX
Lista de Bancos de dados NoSQL mais comuns
http://tinyurl.com/infotechdia16Avaliação da Palestra
@CharlesFortes
PERGUNTAS?
@CharlesFortes