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 (+ programação)

Menos consistência (- 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 Objeto-

Relacionais (BDOR);

Após o crescimento da Web, novos requisitos surgiram: ◦ Manipulação de grandes volumes de dados semi ou não-

estruturados;

◦ 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ão-relacionais 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 chave-

valor.

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