PHPrática 4

Slide para o PHPrática 4

Transcript

1. Aplicando modelo de dados NoSQL com #PHPrática
2. Bancos Relacionais Normalização ACID
3. Modelo Relacional • O modelo relacional é a base para a maior parte dos bancos SQL • Implementação ◦ Tabelas com colunas fixas. ◦ Todas as linhas tem as mesmas colunas • O banco só armazena atributos préviamente definidos/permitidos pelo schema • CREATE TABLE ...
4. Tabela Usuários user_id user_name user_group user_status 1 Freddie guest inactive 2 Roger guest active 3 John admin inactive 4 Brian guest active
5. Tabela Usuários - Normalização user_id user_nam e group_id status_id 1 Freddie 1 1 2 Roger 1 2 3 John 2 1 4 Brian 1 2 group_id group_name 1 guest 2 admin status_id status_name 1 inactive 2 active
6. Por quê normalizamos ? • Menor duplicação dos dados • Menor uso de espaço em disco • Dados altamente consistentes e íntegros
7. Transações • Bancos de dados relacionais normalmente permitem a execução de transações • Transações podem conter múltiplas operações ◦ Diferentes linhas ◦ Diferentes tabelas ◦ E ainda continuam a ser executadas atômicamente Lembra do exemplo clássico da transação bancária ?
8. Garantias ACID • Atomicidade • Consistência • Isolação • Durabilidade
9. Consistência e Integridade • Bancos relacionais proveem muitas maneiras de checar os nossos dados ◦ A nível de Schema ( Colunas e Tipos de dados ) ◦ Referências ( Chaves-estrangeiras, integridade referencial ) ◦ Unique constraints ◦ E outras podem ser definidas pelo usuário
10. Normalização e Desnormalização • É importante normalizar os dados para fazer um uso adequado do banco de dados relacional • A falta de normalização pode causar problemas com a integridade dos dados e pode também dificultar sua recuperação através de consultas SQL. • Desnormalização só é tolerada em favor de desempenho
11. Bancos Relacionais - Problemas • Schema rígido • ORMs • Escalabilidade
12. Bancos Relacionais e dados dinâmicos • Esquemas rígidos dificultam a manipulação de dados dinâmicos • Usar campos BLOB impede o uso de alguns recursos do banco em relação aos dados armazenados • ALTER TABLE ◦ Pode diminuir a performance ou até mesmo bloquear o banco. ◦ Dados precisam ser ajustados quando os Schemas são atualizados ◦ O código da aplicação precisa se manter “ciente” sobre o schema do banco
13. Bancos Relacionais vs Seu Código • ORMs complexos são necessários para converter os dados do banco para a estruturas e tipos de dados da linguagem. • Às vezes um objeto deve ser buscado em várias tabelas, consequentemente usando várias consultas.
14. Bancos Relacionais e Escalabilidade • Escalar bancos relacionais é uma tarefa difícil: ◦ Transações e Joins são custosas para o banco. Se tornam mais custosas ainda quando tem de ser executadas entre múltiplos nós ( Comunicação, Locks ) ◦ A maioria dos bancos relacionais não oferecem suporte nativo para escalabilidade ou particionamento ◦ Muitas vezes o particionamento é implementado na própria aplicação.
15. Bancos de Dados NoSQL
16. O que são ? Uma nova geração de banco de dados, focados principalmente em: • Serem não relacionais • Distribuídos • Open Source ( \o/ ) • Escaláveis horizontalmente
17. O que não são ? ( Ou não pretendem ser) • Substitutos absolutos para os bancos de dados relacionais
18. Por quê ? Os bancos de dados NoSQL surgiram em resposta à esses problemas dos bancos relacionais. Os bancos relacionais tem sido a principal tecnologia de banco de dados há mais de 30 anos. No entanto, enfrentam alguns problemas: • Dificuldade para escalar • Dificuldade para lidar com grandes volumes de dados • Incompatibilidade de Impedância
19. Como ? Os bancos de dados NoSQL abrem mão de alguns recursos comumente encontrados em bancos relacionais em favor da disponibilidade e da distributividade.
20. NoSQL Zoo • O mundo NoSQL não é padronizado ( ainda… ) • O bancos NoSQL não são tão maduros quanto os bancos relacionais.
21. NoSQL = Variedade
22. NoSQL - Queries • Variam muito de um banco para outro • Recursos comuns dos bancos relacionais não estão presentes ou funcionam de uma forma muito diferente nos bancos NoSQL.
23. Categorias de bancos de dados NoSQL
24. Chave-valor • Armazena um mapeamento de uma chave para um valor • Para o banco, o “value” não tem estrutura: Você pode armazenar qualquer coisa. • O valor só pode ser recuperado pela chave. Nem todos os bancos oferecem uma listagem das chaves para que você possa recuperá-las. ( Embora alguns bancos permitam índices secundários para recuperação dos dados ). • Alguns bancos dessa categoria trabalham com o conceito de banco em memória. • Exemplos: Riak, Redis, Memcached
26. Documentos • Documentos semi-estruturados: JSON, BSON, XML • Permite fazer consultas com base nos valores internos do documento. • Exemplos: MongoDB, CouchDB, Azure DocumentDB
28. Família de Colunas • Cada coluna é uma tripla: linha, coluna e timestamp • Colunas são agrupadas em Super Colunas. • Família de colunas: ◦ Colunas de uma mesma família são armazenadas no mesmo sistema de arquivos. • Exemplos: Apache Cassandra, HBase
30. Grafos • Baseado na Teoria dos Grafos ( really nigga ? ) • Os dados são modelados como nós e arestas. Aspectos importantes dos relacionamentos são armazenados também. • Exemplos: Neo4J, InfiniteGraph
32. Coisas a se considerar no NoSQL
33. NoSQL - Coisas a considerar • Schema-less • Trabalham melhor com linguagens dinâmicas
34. NoSQL - Mudanças no schema ? A aplicação pode: • Atualizar todos os dados anteriores • Atualizar os dados eventualmente • Nunca atualizar
35. NoSQL & ACID Na grande maioria dos bancos NoSQL, uma operação que afeta um único registro é atômica. Em operações que afetam mais de um registro o banco pode não garantir a atomicidade, consistência e isolação.
36. NoSQL & ACID Exemplo com dois clientes acessando o mesmo dado em paralelo: READ userA.friends [ userB, userC] READ userB.profile => Ok ! DELETE userB.* => Ok !
37. Teorema CAP Consistência Disponibilidade Tolerância a partições Cada leitura recebe a escrita mais recente ou retorna um erro. Cada requisição recebe uma resposta O sistema continua a operar apesar do número arbitrário de mensagens perdidas entre os nós da rede
38. ACID vs BASE e Teorema CAP • Atomicidade, Consistência, Isolação, Durabilidade • Basic Availability, Soft-State, Eventual consistency • Teorema CAP
39. NoSQL - Consistência Eventual • Bancos NoSQL distribuídos prezam principalmente pela disponibilidade e tolerância a particionamento. • Dados entram em conflito normalmente. • Sua aplicação pode ter que tratar em algum momento dados conflitantes.
40. NoSQL - Consequências para a Modelagem • Se o banco não garante a consistência, então os dados devem ser modelados de maneira que uma entidade lógica deva ser salva como um único registro. • Exemplo: Usuário, Produto • Essa abordagem permite escrever/ler a entidade atomicamente
41. NoSQL - Incorporação • Dados podem ser incorporados e então duplicados no banco de dados. • Exemplo: Incorporar os dados de um ou mais autores no próprio registro de determinado livro. • Isto também facilita a consulta, já que ao recuperar o livro os dados do autor estão embutidos.
42. NoSQL - Incorporação • Pode causar muita duplicação • Atualizações podem ser problemáticas, pois há cópias distribuídas pelo banco e todas elas precisam ser atualizadas. • As próprias cópias podem se tornar inconsistentes
43. NoSQL - Incorporação vs Linkagem • Incorporação deve ser usada: ◦ Quando os dados incorporados muito raramente (ou nunca) sofrem atualizações. ◦ Cache ◦ Quando o tempo de vida da incorporação é curto • Em qualquer outro caso, deve-se usar a linkagem
44. Bancos NoSQL Multi-Modelos
45. O fim da era de modelagem única • Há vida além de tabelas, colunas e relacionamentos. • A persistência poliglota é a possibilidade de se aplicar diversos modelos de dados para a construção de uma aplicação. Pode-se buscar vantagens em cada modelo para a resolução de uma parte do problema e aplicá-la. • Exemplo: ◦ Aplicação de E-commerce: ▪ Sistema de Recomendação: Grafos (Neo4J) ▪ Sessões de usuário: Chave-valor (Riak) ▪ Produtos, Clientes, Vendas: Documentos (MongoDB) ▪ Data-warehouse: Relacional (PostgreSQL)
46. Persistência Poliglota • Nem tudo são flores… • Desvantagens: ◦ Muitas tecnologias envolvidas ◦ Aumento da complexidade E agora, quem poderá nos salvar ?
47. Bancos de Dados Multi-Modelos • Trabalham com dois ou mais modelos de dados • Focam em ser no mínimo tão eficientes em desempenho quanto os bancos NoSQL especializados nos modelos que aborda. • Reduzem os custos de aprendizagem e manutenção. • Exemplos: ArangoDB, CosmosDB, CouchBase, CrateDB
48. Hello, ArangoDB !
49. ArangoDB • Multi-modelos nativo - combina chave-valor, documentos e grafos em uma única instância e uma só linguagem de consulta (AQL) • Escrito em C++ • Extensível através de JavaScript ( Foxx framework, Services ) • Lançamento: 2011 • Atualmente com cerca de 1.4 milhões de downloads • Mais de 180 casos de uso do banco em produção Compania: • ArangoDB GmbH - 2014 • Equipe: 30 pessoas • Sede: Colonia, Alemanha
51. ArangoDB para start up’s ! • O ArangoDB também é uma startup • Oferecem: ◦ Suporte profissional com preço reduzido ◦ Ajudam a desenvolver seu produto rapidamente ◦ Resposta rápida a problemas críticos • ArangoDB GmbH recebeu entre 2016 e 2017 mais de € 6 milhões em investimentos. • Informações: ◦ https://www.arangodb.com/startup-accelerator-program/
52. ArangoDB: Principais recursos • Documentos ◦ JOINS ◦ Transações • Grafos ◦ Distribuídos ◦ Pattern Matching ◦ Transações • Cluster ◦ Recuperação automática de falha ◦ Multi-master
53. ArangoDB Web UI
54. Aplicação prática Construir uma loja de livros. Cada livro deve ter informações como data de publicação, tags relacionadas, autor(es) e editora. O cliente pode ter vários endereços cadastrados para entrega, assim como pode cadastrar mais de um cartão de crédito para efetuar compras na nossa loja. A aplicação deve ainda armazenar os livros visitados pelo cliente, afim de que se possa fazer recomendações futuras ao cliente baseado no que ele procura.
55. Let’s code ! • Obter o Skeleton via composer: composer create-project lvieira/silex-arango-skeleton myProject
56. Referências: • https://www.arangodb.com/2015/10/benchmark-pos tgresql-mongodb-arangodb/ • https://www.arangodb.com/documentation/ • https://docs.arangodb.com/3.1/AQL/index.html • http://nosql-database.org/