Redes Sociais e os Bancos de Dados Não - DECOM-UFOP

Pollyanna Gonçalves
Seminário da disciplina Banco de Dados II

Web 2.0 vem gerando grande volume
de dados
◦ Conteúdo gerado por redes sociais,
sensores inteligentes, tecnologias de
colaboração, etc.

Novas aplicações geram requisitos
diferenciados:
◦ Escalabilidade com a demanda.
◦ Gerenciamento de grande quantidade de
dados semi ou não-estruturados.

Dados Estruturados:
◦ Dados organizados em relações;
◦ São mantidos em um SGBD por manterem a mesma
estrutura de representação, previamente projetada;

Dados Não-Estruturados:
◦ Muitos dados atuais não são mantidos em um
SGBD;
◦ Alta heterogeneidade dificulta consulta a estes
dados;
◦ Não possuem estrutura definida;

Dados armazenados até o ano de 2000:
◦ 800.000 pentabytes (Pb)

Previsão para o ano de 2020:
◦ 35 zerabytes (Zb)

Sozinhos, Twitter e Facebook geram quase
20 terabytes de dados diariamente!
◦ Big Data
◦ Como armazenar de forma eficiente esses dados?

Aplicativos Web geraram necessidades
diferenciadas:
◦
◦
◦
◦
◦
Baixa latência
Alta escalabilidade
Alta disponibilidade
Esquemas flexíveis
Servidores geograficamente distribuídos

Imagine o cenário do Facebook:
◦ Relacionamentos de amigos-em-comum
◦ Relacionamentos de amigos-de-amigos

Pense no conjunto de JOINs de uma consulta
SQL nesses dados para obter informações!

Esquemas flexíveis
Baixo custo
Garante escalabilidade
Maior performance e disponibilidade

Linguagem query não-declarativa

Menos consistência



(+ programação)
(- garantias)


SQL foi sucesso na década de 70 com sistemas
para manipulação de dados convencionais (ex.:
sistemas de controle de estoque, folhas de
pagamento, etc.)
A evolução das aplicações de BDs gerou a
necessidade de manipulação de outros formatos de
dados (ex. imagem, som, vídeo, etc.)
◦ Soluções: BDs Orientados a Objetos (BDOO) e BDs ObjetoRelacionais (BDOR);

Após o crescimento da Web, novos requisitos
surgiram:
◦ Manipulação de grandes volumes de dados semi ou nãoestruturados;
◦ Escalabilidade;
SOLUÇÃO:
 NoSQL = Not Only SQL (“Não apenas SQL”)
◦ SGBDs que não adotam modelos de BDs relacionais

Inicialmente, propostas de bancos de dados nãorelacionais foram desenvolvidas por pequenas
empresas e comunidades de software livre.

Escalabilidade Horizontal

Ausência de Esquema

APIs simples para acesso de dados

Consistência eventual

Não respeita propriedades ACID

Escalabilidade Horizontal:
◦ Aumento no número de máquinas disponíveis
para o armazenamento e processamento de
dados:
 Requer que diversas threads/processos de uma tarefa
sejam criadas e distribuídas;
 Em um BD relacional, esse processo causaria uma alta
concorrência, aumentando o tempo de acesso às tabelas
envolvidas;
◦ É permitida pela ausência de bloqueios, que torna
a tecnologia adequada para solucionar problemas
de gerenciamento de grande volumes de dados.

Ausência de Esquema:
 Esquema: relação e seu conjunto de atributos.
◦ Facilita a escalabilidade e contribui para um maior
aumento da disponibilidade;
◦ Problema: não há garantias da integridade dos
dados;

APIs simples para acesso de dados:
◦ O foco não está mais em como os dados são
armazenados e sim como poderemos recuperá-los
de forma eficiente;
◦ Desenvolvimento de APIs baseadas em NoSQL que
facilitam acesso a essas informações;

Consistência eventual:
◦ Teorema CAP (Consistency, Availability e Partition
tolerence):
 Só será possível garantir duas das três propriedades:
 Consistência: uma leitura de um item após uma escrita
desse item deve retornar o novo valor.
 Disponibilidade: propriedade de um sistema responder a
todas as requisições que chegam a
um nó funcionando.
 Tolerância à partição: propriedade de
um sistema continuar funcionando
mesmo quando um problema ocorre
na rede dividindo o sistema em duas
ou mais partições.

Consistência eventual:
◦ No contexto de aplicações da Web 2.0, há
geralmente a preferência por disponibilidade
quando for possível tolerar alguma consistência
temporária.
◦ BASE (Basically Available, Soft state, Eventual
consistency), em oposição à ACID:
 Indica que devemos planejar um sistema de
forma a tolerar inconsistências temporárias
quando se quer priorizar disponibilidade.

Não respeita propriedades ACID:
◦ Conjunto de propriedades que garantem a
consistência dos dados:
 Atomicidade: transação será totalmente executada ou
não será executada.
 Consistência: consistência entre início e fim das
transações.
 Isolamento: operações de transações não serão vistas
por outras até seu encerramento.
 Durabilidade: persistência de uma transação após seu
encerramento.

Tipos mais comuns de banco de dados
NoSQL:
◦
◦
◦
◦
Chave-valor (key-value)
Orientado a Documentos
Orientado a Grafos
Orientado a Colunas

Chave-valor (key-value):
◦ Simples e permite a visualização do banco de
dados como uma grande tabela hash;
◦ Armazenam objetos indexados por chaves;
◦ Possibilitam a busca por objetos a partir de suas
chaves;
◦ Operações simples para manipulação dos dados:
get( ) e put( ) ;
◦ Problemas:
 Muitos dados não são facilmente modelados como chavevalor.

Chave-valor (key-value):

Orientados a Documentos:
◦ Conjunto de documentos com conjunto de
campos (chaves) e o valor deste campo para cada
um;
◦ Não depende de um esquema rígido
(possibilidade de atualização na estrutura do
documento, com a adição de novos campos, sem
causar problemas ao BD);
◦ Exemplos: XML, JSon, etc.

Orientados a Documentos:

Orientado a Grafos:
◦ Operações sobre dados são transformações sobre
grafos, fazendo uso de conceitos já estabelecidos
(vizinhos, caminhos, subgrafos, etc.)
◦ Menor redundância e replicação desnecessária;

Orientado a Colunas:
◦ Dados indexados por uma tripla (linha, coluna e
timestamp);
◦ Linhas e colunas são identificadas por chaves;
◦ Timestamp diferencia múltiplas versões de um
mesmo dado;
◦ Todos os dados de um registro são colocados no
disco com uma única escrita no banco (+ rapidez)
◦ Problema: leitura de apenas algumas colunas;

Cada tipo de modelo pode ser mais adequado
para determinadas aplicações:

Facebook:
◦ Para evitar problemas com a escalabilidade e
disponibilidade dos dados, a empresa desenvolveu
o Cassandra, uma solução NoSQL.
◦ Inicialmente criado para otimização do sistema de
busca da rede social.

Twitter:
◦ A preocupação com o problema de disponibilidade
fez com que a empresa substituísse o banco de
dados MySQL pelo Cassandra.
◦ Utiliza-o para armazenar resultados de data
mining para resultados de trend topics, top
tweets e análises em tempo real em larga escala.
◦ Aumentou em quase 30% a disponibilidade do
sistema em 2010, quando comparado a 2008.

Google:
◦ Desenvolveu sua própria solução NoSQL, o
BigTable.
◦ Sistema de armazenamento distribuído para
gerenciar dados em larga escala.
◦ Utilizado pelo Gmail, Google Docs, Google
Analytics, Orkut, Google Earth, etc.
◦ Permitiu a escalabilidade de recursos e melhora
na performance no processamento de consultas.

Amazon:
◦ Desenvolveu o Dynamo, em 2007.
◦ Garante alta disponibilidade dos dados de seus
serviços “always-on”.
◦ Resultados:
 Amazon tem se mantido disponíveis em 99,9995%
das requisições realizadas.

LinkedIn:
◦ Empresa desenvolveu sua própria solução NoSQL, o
Voldemort.
◦ Suporta escalabilidade horizontal, replicação,
particionamento, transparência a falhas, etc.

Vantagens x Desvantagens:
◦ Devemos procurar a solução ideal para o problema.

Modelo híbrido:
◦ Tentar aproveitar da melhor forma ambas as abordagens
(SQL e NoSQL).




Consistência eventual não é intuitiva para
programação.
Portabilidade pode ser um problema.
Aplicável em cenários onde seja possível trabalhar
com menor consistência dos dados (ACID x CAP).
NoSQL não irão substituir bancos de dados
relacionais!
◦ NoSQL são eficientes para aplicações que envolveu grande
volume de dados com alta demanda de escalabilidade.




“Introduction to NoSQL Databases” - Chyngyz Omurov,
Osman Tursun
“NoSQL”- Perry Hoekstra
“NoSQL no desenvolvimento de aplicações Web
Colaborativas” - Bernadette Farias, Hélio Rodrigues de
Oliveira, Jonas César de Sousa Pontes
“NOSQL na Web 2.0: Um Estudo Comparativo de Bancos
Não-Relacionais para Armazenamento de Dados na Web
2.0” - Mauricio De Diana, Marco Aurélio Gerosa1