Material Seminário NoSQL
Upcoming SlideShare
Loading in...5
×
 

Material Seminário NoSQL

on

  • 1,222 views

Material para seminário com abordagem sobre NoSQL apresentada para avaliação da matéria de Banco de Dados II da Universidade de Vila Velha. ...

Material para seminário com abordagem sobre NoSQL apresentada para avaliação da matéria de Banco de Dados II da Universidade de Vila Velha.

Apresentação: https://www.slideshare.net/lorran33/seminrio-nosql

Alunos: Iago Binow, Lorran Pegoretti, Luiz Marcon e Pedro Malta

Universidade de VIia Velha.

Statistics

Views

Total Views
1,222
Views on SlideShare
1,222
Embed Views
0

Actions

Likes
0
Downloads
43
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Material Seminário NoSQL Material Seminário NoSQL Document Transcript

    • Universidade de Vila Velha – UVV Curso de Ciência da Computação – Turma CC4M Banco de Dados II Material para apresentação de seminário – 23/11/2012 NOSQL Apresentação: http://pt.scribd.com/doc/114144652/Grupo: Iago Binow, Lorran Pegoretti, Luiz Marcon e Pedro MaltaProfessor: Sandro Tonini Vila Velha 2012
    • “NoSQL is not about any one feature of any of the projects. NoSQL is not aboutscaling, NoSQL is not about performance, NoSQL is not about hating SQL, NoSQLis not about ease of use, NoSQL is not about sharding, NoSQL is not aboutthroughput, NoSQL is not about speed, NoSQL is not about dropping ACID, NoSQLis not about Eventual Consistency, NoSQL is not about CAP, NoSQL is not aboutopen standards, NoSQL is not about Open Source and NoSQL is most likely notabout whatever else you want NoSQL to be about. NoSQL is about choice.” Jan Lehnardt, CouchDB
    • HistóricoO termo NoSQL foi usado pela primeira vez em 1998 como o nome de um banco de dadosrelacional de código aberto que não possuía um interface SQL. Seu autor, Carlo Strozzi, alegaque o movimento NoSQL “é completamente distinto do modelo relacional e portanto deveria sermais apropriadamente chamado “NoREL” ou algo que produzisse o mesmo efeito”. Porém otermo só voltou a ser assunto em 2009 por um funcionário do Rackspace, Eric Evans, quandoJohan Oskarsson da Last.fm queria organizar um evento para discutir bancos de dados opensource distribuídos.NoSQL são diferentes sistemas de armazenamento que vieram para suprir necessidades queos bancos de dados tradicionais(Relacionais) são ineficazes. Muitas dessas bases apresentamcaracterísticas muito interessantes como alta performance, escalabilidade, replicação, suporteà dados estruturados e sub colunas.O NoSQL surgiu da necessidade de uma performance superior e de uma alta escalabilidade.Os atuais bancos de dados relacionais são muito restritos a isso, sendo necessário adistribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco umservidor precisa. O NoSQL tem uma grande facilidade na distribuição horizontal, ou seja, maisdados, mais servidores, não necessariamente de alta performance. Um grande utilizador desseconceito é o Google, que usa computadores de pequeno e médio porte, para a distribuição dosdados, essa forma de utilização e muito mais eficiente e econômica. Além disso, os bancos dedados NoSQL são muito tolerantes a erros.No caso dos bancos NoSQL toda a informação necessária estará agrupada no mesmo registro,ou seja, em vez de você ter o relacionamento entre várias tabelas para formar uma informaçãoela estará em sua totalidade no mesmo registro.[1]Descrição Wikipédia: NoSQL é um termo genérico para uma classe definida de banco dedados não-relacionais que rompe uma longa história de banco de dados relacionais compropriedades ACID. Outros termos equivalentes para esta categoria de bancosé NF², N1NF (non first normal form), nested relational, dimensional, multivalue, free-form, schemaless, document database e MRNN (Modelo Relacional Não Normalizado).(Uma tabela está na 1FN, se e somente se, não possuir atributos multivalorados. Em outraspalavras podemos definir que a primeira forma normal não admite repetições ou campos quetenha mais que um valor.)Características- Escalabilidade Horizontal (scale out)Significa adicionar mais nós ao sistema, tais como adicionar um novo servidor e um sistema desoftware que permita a distribuição do trabalho entre múltiplas máquinas. [2]- Replicação – Escalar por duplicação de informaçõesConsiste na copia das informações em mais de um banco para aumentar a capacidade derecuperar estas informações. Podem ser divididas em duas “arquiteturas” principais:
    • Master-Slave: Cada escrita em banco resulta em X escritas onde X é o número de slaves. Neste caso um banco “Master” propaga cada write para os bancos “slaves”. Isto aumenta a velocidade de leitura, mas não melhora a capacidade de escrita. Multi-Master: Aumenta-se o número de Masters no sistema e assim aumenta a capacidade de escrita. - Schema-free Um dos fatores que contribuem para um banco de dados NoSQL escalar é por causa da ausência de um schema (schema free). Todos os novos bancos tem em comum que eles são key-value stores, ou seja, salvam como o nome sugere, um conjunto de entradas formadas por uma chave associada a um valor e o valor poderia ser de qualquer tipo, um binário ou string que está sendo salvo de forma desnormalizada (schema-free). - Clusterização Basicamente compreende um banco de dados armazenado e gerenciado por mais de um servidor, provê uma alta disponibilidade e um alto desempenho do sistema. Assim, a organização se beneficia diminuindo o tempo de inoperabilidade do banco de dados. Esse processo vem como uma solução para reduzir gastos com estrutura de hardware. [4] - Mapreduce É um algoritmo, patenteado pela Google para gerenciamento em larga escala. [3] Existem duas fases: Map: O nó principal recebe os dados, divide e partes menores e as envia aos outros nós para serem processados. Ao final do processamento estes nós devolvem o resultado ao nó principal. Reduce: O nó principal combina as respostas obtidas pelos outros nós gerando o resultado final do processamento. - Sharding Consiste em dividir os dados horizontalmente, ou seja, quebrar as tabelas, diminuindo o seu número de linhas e separando-as em ambientes diferentes. Neste ponto todos os dados de uma partição não devem conter referências aos dados de outras partições, sendo que os dados em comum deverão ser replicados entre as bases. [3] Classificação Key/Value Store Esse é o tipo de banco de dados NoSQL mais simples o conceito dele é uma chave e um valor para essa chave, mas ele é o que aguenta mais carga de dados. Esses tipos de bancos de dados são o que tem a maior escalabilidade. [1] Amazon SimpleDB Azure Table Storage Berkeley DB Chordless Dynomite GenieDB: GenieDB is designed to be a pragmatic solution to a widespread class of data storage problems, with a high-performance native API alongside compatability with MySQL.
    •  GT.M / M.DB HamsterDB Hibari: Hibari is a production-ready, distributed, key-value, big data store. Hibari uses chain replication for strong consistency, high-availability, and durability. Hibari has excellent performance especially for read and large value operations. KAI KaTree Kumofs LightCloud Membase Memcachedb Mnesia NorthScale Orient Key/Value Server Pincaster PNUTS/Sherpa Project Voldemort: LinkedIn open source implementation of Amazon Dynamo key-value store Redis Riak: Dynamo-inspired key/value store that scales predictably and easily. Scalaris ScalienDB / Scalien Keyspace a distributed, consistent key-value store Tokyo Cabinet [5] Wide Columns Store Fortemente inspirados pelo BigTable do google eles suportam várias linhas e colunas, além disso ele permite sub colunas. [1] BigTable Cassandra: a highly scalable second-generation distributed database, bringing together Dynamo’s fully distributed design and Bigtable’s ColumnFamily-based data model. HBase Hypertable [5] Document Store Baseado em documentos XML ou JSON, podem ser localizados pelo seu id único ou por qualquer registro que tenha no documento. [1] Colayer
    •  CouchDB FleetDB Jackrabbit Lotus Notes MongoDB OrientDB Raven DB ThruDB Terrastore [5] Graph Store Com uma complexibilidade maior esses bancos de dados guardam objetos e não registros como os outros tipos de NoSQL. A busca destes itens são feitas pela navegação destes objetos. AllegroGraph Bigdata Core Data DEX: a high-performance graph database written in Java and C++. Its main characteristic is its performance storage and retrieval for large graphs, in the order of billions of nodes, edges and attributes, implemented with specialized structures. Filament FlockDB HyperGraphDB InfiniteGraph InfoGrid Neo4j OpenLink Virtuoso Sones VertexDB Trinity: a graph database and computation platform over distributed memory cloud. As a database, it provides features such as highly concurrent query processing, transaction, consistency control. As a computation platform, it provides synchronous and asynchronous batch-mode computations on large scale graphs.[5] Exemplo Facebook – Cassandra, 2008 Como identificamos, o NoSQL não é uma negativa ao SQL tradicional, apesar do que o acrônimo aparenta. NoSQL procura suprir necessidades em que o SQL puro é engessado ou as regras de consistência "ACID" (Atomicidade, Consistência, Isolamento e Durabilidade)
    • podem ser suprimidas ou são desnecessárias, ou então podem ser negligenciadas em buscade maior escalabilidade.Nesse cenário um ator de destaque é o Facebook. Não há como falar de necessidade deescalabilidade sem citar essa máquina devoradora de Bytes, segundo o conceituado siteGIGAOM no artigo "Facebook shares some secrets on making MySQL scale" o Facebookingere mais de 500 terabytes de novas informações por dia. Há de se esperar que exista umasolução inovadora e fantástica por trás disso tudo, na verdade não tanto, o Facebook utilizanas suas partes principais o bom e velho MySQL, bem, o MySQL tunado do Facebook, masainda assim MySQL.Porém para certos casos e atividades específicas o Facebook implementa tecnologia NoSQL,inclusive já liberou opensource o Cassandra, hoje conduzido pela fundação Apache. SegundoAvinash Lakshman, um dos incubadores do Cassandra e funcionário do Facebook, oCassandra foi desenvolvido para solucionar a busca no bate-papo do Facebook, o bate-papodo Facebook foi um dos produtos mais complexos a ser desenvolvido, ele integra SMS, e-mail,inbox e o chat online, um parte que recebe uma massiva quantidade de dados. A estrutura doCassandra é totalmente avessa a primeira forma normal, uma coluna pode ter várias colunas.Veja como a estrutura é perfeita para um sistema de mensagens: uma coluna tem um nome,um valor(que podem ser várias colunas) e um "timestamp". Hoje em dia o sistema demensagens funciona em cima de outra tecnologia NoSQL, o HBase, mas de funcionamentoparecido.Outra parte importante em que o NoSQl aparece é na análise dos dados, ou na gerenciamentodo MetaDados do Facebook, essa parte é levada pela integração do HBase com o Hive, dadosmais antigos são transferidos do MySQL para o HBase, para formação de um Data Warehousee o Hive faz a análise desses dados, é possível inclusive fazer consultas SQL pelo Hive, emcima do HBase, que não tem esse suporte.Esses casos tendem a aumentar pois quando o Facebook construiu seu ambiente MySQL nãohaviam tecnologias NoSQL, portanto há em sua base dados que não são estruturados ou sãosemiestruturados. A medida que as tecnologias NoSQL amadurecem haverão maisimplementações em aplicações do mundo real. [7] [8] [9]Os maiores mitos sobre NoSQLNoSQL é escalávelUma das grandes promessas dos bancos NOSQL consiste em dizer que eles são maisescaláveis que os bancos de dados relacionais. O problema com esta mensagem que évendida por algumas empresas é que ela não é inteiramente verdade. Dizer que seu sistemaescala sozinho é vender um sonho. Ele pode até ser mais fácil de escalar se comparado aoutras soluções mas ainda sim exigira algum esforço para escalar.Não precisamos de DBAsNo mundo dos bancos relacionais a figura do DBA sempre está presente. Com sistemas quetem particularidades para cada vendor os DBAs ficam a cargo de instalar, configurar e mantercada banco de dados em suas particularidades. Muita gente diz que quando se trabalha comNoSQL não precisamos de DBAs. Acredito que talvez não no sentido tradicional, mas aindavamos precisar de alguém responsável por lidar com o banco e com o acesso aos dados. Estafunção pode vir a se tornar parte do trabalho de um desenvolvedor ou se tornar a função fulltime de alguém no seu time que pode ser até um DBA com conhecimentos em NoSQL. Emaplicações reais em produção muito provavelmente será necessário misturar bancosrelacionais e não relacionais, possuir alguém que navegue facilmente nos dois mundos em seutime é uma grande vantagem.
    • NoSQL é mais econômicoMeia verdade. Muitos vendors de NoSQL afirmam que suas soluções vão baratear o custo dosseus clientes. Em parte sim, em algumas situações o custo em usar um banco de dadosrelacional pode ser proibitivo devido à escala ou a licenças envolvidas. Existem muitos casosentretanto que uma solução relacional atende perfeitamente todas as necessidades do clientee ainda sim pode ser considerada barata. Bancos de dados open source como MySQL ePosgreSQL são usados sem problemas por um grande número de aplicações com sucesso.ConclusãoSe você está começando agora com o NoSQL, cuidado para não cair em armadilhas. Sempreinteraja com a comunidade, converse com outros desenvolvedores sobre suas experiênciasreais com NoSQL e não se esqueça de deixar suas dúvidas nos comentários. Se você jápossui alguma experiência, quais outros mitos você vê com relação ao NoSQL ? [6]Referencias:  [1] “Introdução ao NoSQL.” http://www.nosqlbr.com.br  [2] Edmar Ferreira, “Escolhendo entre escalabilidade horizontal e escalabilidade vertical”. http://escalabilidade.com/2010/09/21/escolhendo-entre-escalabilidade-horizontal-e- escalabilidade-vertical/  [3] Edmar Ferreira, “Introdução ao NoSQL parte II” http://escalabilidade.com/2010/04/06/introducao-ao-nosql-parte-ii/  [4] InfoWester “Cluster: Principais Conceitos”, http://www.infowester.com/cluster.php  [5] “NoSQL” http://nosql.mypopescu.com/kb/nosql  [6] “Os Maiores mitos sobre NoSQL” http://escalabilidade.com/2010/10/08/os-maiores-mitos-sobre-nosql/  [7] “Inside Facebook Messages Application Server” https://www.facebook.com/note.php?note_id=10150162742108920  [8] “Hive – The next generation data warehouse” http://blogs.impetus.com/big_data/hadoop_ecosystem/Hive.do  [9] “Cassandra – A structured storage system on a P2P Network https://www.facebook.com/note.php?note_id=24413138919