2º Meritt CC - NoSQL - E o Futuro dos Bancos de Dados na Web
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

2º Meritt CC - NoSQL - E o Futuro dos Bancos de Dados na Web

on

  • 738 views

Apresentação da segunda edição do evento Meritt CC, espaço semanal onde cada meritt pode compartilhar seu conhecimento. ...

Apresentação da segunda edição do evento Meritt CC, espaço semanal onde cada meritt pode compartilhar seu conhecimento.

Nesta apresentação, Fernando Jorge Mota <fjorgemota@meritt.com.br> apresentou o conceito de banco de dados NoSQL e três de suas implementações: 1) MongoDB, 2) Cassandra e 3) HBase.

Um dos objetivos é que a equipe esteja melhor preparada para quando surgirem desafios que exigirão o uso de diferentes bancos de dados.

Statistics

Views

Total Views
738
Views on SlideShare
738
Embed Views
0

Actions

Likes
2
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution 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

2º Meritt CC - NoSQL - E o Futuro dos Bancos de Dados na Web Presentation Transcript

  • 1. NoSQL E o futuro dos bancos de dados na web
  • 2. Visão Geral ● Usado em empresas como Google, Facebook e Twitter. ● Criado pelo Google através de um documento sobre seu banco de dados interno, o BigTable. ● Inúmeras implementações. ● Altíssima Performance. ● Altamente escalável, especialmente entre vários computadores. ● Limita número de consultas possíveis.
  • 3. Principais vantagens ● Uso de MapReduce ● Armazenamento de grandes quantidades de dados ● Respostas praticamente instantâneas. ● Grande adoção por grande parte das empresas. ● É fácil encontrar suporte para BD's NoSQL na internet. ● Grande ritmo de atualizações.
  • 4. Principais desvantagens ● A complexidade que você evita no modelo de banco de dados é repassada para o seu código, para o seu aplicativo. ● Necessário bom nível de conhecimento (e paciência) para se obter um bom uso.
  • 5. Diferenciais no schema ● Modelar um banco de dados relacional é na maioria das vezes...fácil. No NoSQL, entretanto, por existir várias implementações de bancos de dados, cada software costuma ter seu próprio esquema de dados.
  • 6. Modelo base ● Nome do banco de dados: my_product ● Para o banco de dados: MariaDB/MySQL. ● Schema de dados:
  • 7. MySQL - Inserir ● INSERT INTO users VALUES(1, "Fernando", "123"); ● INSERT INTO favorites VALUES(NULL, "Meritt", 1);
  • 8. MySQL - Editar ● UPDATE usuarios SET nome="Fernando Jorge Mota" WHERE id=1; ● UPDATE favorites SET obj="Meritt e Python" WHERE user=1;
  • 9. MySQL - Apagar ● DELETE FROM favorites WHERE user=1;
  • 10. MySQL - Visualizar ● SELECT * FROM favorites WHERE user=1; ● SELECT * FROM favorites;
  • 11. Implementações ● Para esta apresentação, foram selecionados três bancos de dados que merecem nossa atenção. São eles: ○ MongoDB ○ Apache Cassandra ○ Apache Hive
  • 12. MongoDB - Visão Geral ● Criado e suportado pela 10gen. ● Cada registro pode ter no máximo 16 MB. ● Suporte à consultas MapReduce em JavaScript. ● Armazena documentos, sendo o banco de dados NoSQL mais semelhante à um banco de dados relacional. ● Aggregate Framework substitui consultas simples do MySQL. ● Suporte à sharded clusters e replica sets.
  • 13. MongoDB - Vantagens ● Drivers para inúmeras linguagens. ● Simples de usar. ● Multiplataforma. (roda até em Windows!!1) ● Possui alta performance. ● Fácil criação de clusters de máquinas com os sharded clusters. ● Alta confiabilidade com os replica sets. ● Por ser feito em C++, possui fácil instalação e possui pacotes para inúmeras distribuições Linux, facilitando a atualização.
  • 14. MongoDB - Desvantagens ● Conhecido por possuir grande consumo de memória. ● Vem com modo confiável de escrita desativado por padrão. (é possível ativar manualmente) ● Demora até 100ms para gravar os dados efetivamente no disco. ● Não comprime eficientemente os dados.
  • 15. MongoDB - Schema ● Por ser orientado a documentos, o schema permanece o mesmo que o de um banco de dados relacional, pelo menos para este caso. ● Dependendo do caso, obviamente o schema muda. Por exemplo, uma relação num banco de dados relacional pode virar um sub-documento no MongoDB..Ou virar uma lista, apenas..Enfim.
  • 16. MongoDB - Inserir ● db.my_product.users.insert ({"username":"Fernando", "password":" 123","_id":1}); ● db.my_product.favorites.insert({"obj":" Meritt", "user": 1});
  • 17. MongoDB - Editar ● db.my_product.users.update({"_id":1}, {"$set":{"username":"Fernando Jorge Mota"}}); ● db.my_product.favorites.update({"user": 1}, {"$set":{"obj":"Meritt e Python"}});
  • 18. MongoDB - Apagar ● db.my_product.favorites.remove({"user": 1});
  • 19. MongoDB - Consultar ● db.my_product.favorites.find({"user":1}) ● db.my_product.favorites.find()
  • 20. Cassandra - Visão Geral ● Altíssima velocidade. ● Desenvolvido internamente pelo Facebook e mantido atualmente no incubador do Apache Foundation. ● Alta confiabilidade. ● Uso de compressão eficiente de dados. ● Bela arquitetura de dados. ● Possui o melhor do DynamoDB (Amazon) e BigTable (Google)
  • 21. Cassandra - Vantagens ● Armazenamento de enormes quantidades de dados ● Relativamente simples de usar. ● Alta velocidade de escrita. (maior do que de leitura) ● Possui suporte ao CQL, ou Cassandra Query Language, que lembra um pouco consultas SQL. ● Se integra (ainda experimentalmente) com MariaDB, para armazenamento de dados e consultas simples. ● Armazenamento chave-valor.
  • 22. Cassandra - Desvantagens ● Dificuldade para fazer consultas SIMPLES sem uso de ferramentas adicionais. ● Consultas MapReduce? Só com Hadoop e em Java (ou Hadoop+Hive e um tipo maluco de linguagem SQL) ● Possui poucos drivers. (que são suportados pela comunidade e são muito pouco atualizados)
  • 23. Cassandra - Schema ● No Cassandra, o modelo relacional persiste, mas em partes: O uso de indíces com grande variação de dados não é recomendado, e os itens são acessados diretamente através da sua chave primária.
  • 24. Cassandra - Inserir ● set users[1][username] = Fernando; ● set users[1][password] = 123; ● set favorites[1][obj] = Meritt; ● set favorites[1][user] = 1;
  • 25. Cassandra - Editar ● set favorites[1][obj] = 'Meritt e Python';
  • 26. Cassandra - Apagar ● del favorites[1];
  • 27. Cassandra - Consultar ● get favorites[1]; ● list favorites;
  • 28. Cassandra - Observação ● Sim, jovem padawan. 100% do que é possível fazer com o Apache Cassandra precisa do uso de uma chave primária conhecida. ● É até possível utilizar indices secundários, que permitiriam o uso de qualquer campo. Mas aí entra alguns fatores limitadores, como a não recomendação de usar como indíce campos que não se repetem frequentemente, por exemplo..
  • 29. HBase - Visão Geral ● Alta velocidade. ● Alta confiabilidade. ● Suporta bilhões de linhas com milhões de colunas cada. ● É mantido na Apache Foundation, assim como o Apache Cassandra. ● Modelado de acordo com o Google BigTable
  • 30. HBase - Vantagens ● Armazenamento de enormes (mas ENORME mesmo) quantidades de dados ● Alta velocidade de escrita.
  • 31. HBase - Desvantagens ● Dificuldade para fazer consultas SIMPLES sem uso de ferramentas adicionais. ● Consultas MapReduce? Só com Hadoop e em Java (ou Hadoop+Hive e um tipo maluco de linguagem SQL) ● Possui poucos drivers. (que são suportados pela comunidade e são muito pouco atualizados)
  • 32. HBase - Schema ● O schema no HBase é similar ao que é possível encontrar no Cassandra. A maior diferença, entretanto, é que enquanto no Cassandra é possível separar por família de colunas (ID) ~> colunas, no HBase fica tudo misturado. ● Além disso..
  • 33. HBase - Ops.. ● Durante os testes com o HBase notou-se que a configuração é díficil. ● É tão díficil e mal documentada que eu iria gastar mais tempo tentando resolver os problemas da plataforma do que fazendo este slide, por si só. Enfim, tudo o que sabemos é que, de fato, dizem que ele consegue armazenar grandes quantidades de dados..mas será que vale trocar pela dificuldade na configuração?
  • 34. Conclusão Durante o uso dos três bancos de dados percebi que: ● MongoDB é legal para aplicações que precisam de alta velocidade, suporte à clusters mas ainda com estrutura similar ao que é possível encontrar relacionalmente. ● Cassandra é legal se você quer alta velocidade de escrita. E tem paciência.
  • 35. Conclusão Durante o uso dos três bancos de dados percebi que: ● HBase é legal......se você tiver tempo para entender sua natureza obscura. ● Sobre o NoSQL... Se você quer entender definitivamente o por quê suas consultas no MySQL estão lentas, e se você quer que o seu banco de dados escale com facilidade entre vários computadores.
  • 36. Conclusão ● É isso..Dúvidas? :D