Upload
doanphuc
View
218
Download
0
Embed Size (px)
Citation preview
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.
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.
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;
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