Apresentação utilizada no InfoTech2012.
Apresenta um pouco sobre a evolução a persistencia de dados, bancos de dados relacionais e NoSQL, apresentando um pouco os melhores cenários para se utilizar cada um dos modelos e como mesclá-los para tirar o melhor proveito dos recursos.
4. 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.
5. 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
6. 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.
7. 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.
8. A conclusão desta necessidade foi o aparecimento dos
bancos de dados.
10. Hoje quandopensamos em banco de dados, sempre nos
vem em mente os bancos de dados relacionais, como o
SQLServer, Oracle, MySQL, Postgree, MSAccess (há! #euri)
11. Apesar de não ser o único modelo de banco de
dados possível, o modelo relacional é considerado o
mais maduro.
12. "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"
13. O banco de dados relacional é composto a grosso
modo de Relações e Relacionamentos.
14. 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).
15. Relacionamentos dizem respeito a como um registro está relacionado
a outro registro de outro domínio (Ex.: Um fabricante possui um ou
mais produtos)
16. Este é modelo que chamamos de Entidade Relacionamento (ou
Entidade Relacional dependendo do autor)
17. 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
18. 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...
19. ...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...
20. ...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
21. nos 1.000 primeiras páginas isso foi moleza, mas depois da nº
1.000.000.000 isso começou a complicar um pouco...
23. 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.
24. O modelo surgiu diante do aumento crescente de
dados não relacionais (fotos, logs, documentos,
capturas de sensores, etc.)
25. 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.
26. 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.
28. 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.
30. 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"
31. 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
32. 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
33. 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.
34. 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
35. 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
36. 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.
38. 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
39. 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.
40. Lista de Bancos de dados
NoSQL mais comuns
• Documento
o RavenDB
o CouchDB
o MongoDB
o MarkLogic Server
o BaseX
o eXist
• Chave/Valor (Key/Value)
o Memcachedb
o Project Voldemort
o Redis
o SimpleDB
o Hbase
• Tabular
o Cassandra
o Hypertable
• Gráfos
o Neo4j
o DEX