Parte da série sobre o resumo do livro Designing Data Intensive Apps.
No capítulo 1 vimos alguns atributos de sistemas de dados: reliability, scalability e maintainability.
No capítulo 2, o autor explica diferentes tipos de modelos de dados, principalmente os modelos relacional, documento e grafo.
Modelo relacional
Nos anos 60 e 70, os modelos de dados dominantes eram o Network
Model e o Hierarchical Model.
“File:Bachman order processing model.tiff” by Mhkay is licensed under CC BY-SA4.0
“File:Hire.png” by Tsedenjav.Sh is licensed under CC BY-SA 4.0
Mas nos anos 80, o modelo relacional dominou o mercado e esses outros dois modelos se tornaram obsoletos. Isso se deve a dois problemas principais com esses modelos.
Relações many-to-many
No modelo hierárquico, era bem possível representar relações one-to-many, mas não era possível representar relacionamentos many-to-many. Vendo na figura acima, o modelo hierárquico é como uma árvore, ou seja, os nós podem ter muitos filhos, mas cada nó só pode ter um nó ancestral. Nessa estrutura, representar um modelo de "Produtos" e "Pedidos" fica difícil, pois um pedido pode ter vários produtos, mas não é possível o mesmo produto também estar em varios pedidos.
Linguagem de consulta
Os modelos de rede, CODASYL o mais conhecido, relacionamentos many-to-many eram possíveis. Inclusive é um modelo um pouco semelhante ao modelo de grafos que vamos ver mais adiante. Isso já era uma grande vantagem sobre o modelo hierárquico. Porém, o principal problema deste modelo na época era com consultas aos dados.
Por exemplo, se em um modelo de dados como: Escola → Turmas → Alunos, se voce quisesse acessar o dado de um aluno, era necessário percorrer os nós Escola e Turmas para chegar ao dado do aluno.
Além disso, essas consultas eram escritas em linguagens bem imperativas, que, apesar de ter boa performance para a época, eram difíceis de escrever e relativamente frágeis com relação a mudanças no modelo de dados.
Em meados da década de 80, surge os primeiros RDBMS, que além de suportar relacionamentos many-to-many, também tinham uma linguagem de consultas, SQL, bem poderosa, expressiva e declarativa, que permitia ao analista escrever quais
dados a consulta deve retornar, e não como a consulta deve retornar os dados. Com avanços no desenvolvimento das engines de planos de execução de SQL, performance deixou de ser um problema.
Modelo de documentos
No inicio dos anos 2010, depois de quase 30 anos de dominio do modelo relacional, começou a entrar em voga questionar o absolutismo do SQL, por algumas razões, principalmente:
Necessidade de escalabilidade com alto volume de escrita. Ao contrário da década de 80 e 90, agora em 2010 acesso à computadores é mais democratizado e existe a internet, no começo do boom das redes sociais e bilhões de posts por dia. Em um banco de dados relacional, dados consistentes são garantidos, e isso pode after performance de escrita.
Em bancos de dados relacionais, os dados também devem seguir um schema pré-definido. Muitos dos grandes sites dessa época eram escritos em linguagens como Ruby/Rails que pregam uma abordagem mais dinâmica, flexível e expressiva. RDBMSs com seus requerimentos de schema, e também com o problema da Impedância Objeto-Relacional criaram um ambiente que trouxe ideias lá da década de 70 de volta, com uma cara nova. Os modelos NoSQL (Não Relacionais) como Key-Value Stores e Document
Databases começaram a aparecer nesse periodo.
O modelo de documentos por exemplo, é bem parecido com o modelo hierárquico e tem nativamente a mesma restrição com relacionamentos many-to-many, além disso, Document Databases não costumam oferecer suporte a joins entre tabelas. Porém, modelos de documentos favorecem manter dados relacionados próximos, no mesmo documento, evitando assim a necessidade de joins.
Relacional ou Não relacional
A resposta é sempre: depende.
Algumas vantagens do modelo não relacional sobre o relacional:
Flexibilidade de schema: Isso não quer dizer que não há schema. Ele existe. Só que em um modelo de documentos, existe o que é chamado de Schema on Read: o schema não é forçado pelo banco de dados, mas geralmente validado e tratado pela aplicação.
Localidade de dados: um documento geralmente contem todos os dados relacionados a uma entidade, sem a necessidade de joins em outros documentos.
Não há necessidade de ORMs.
Vantagens do banco relacional sobre o não relacional
Suporte nativo a relacionamentos entre entidades, inclusive many-to-many, e joins entre entidades feitos pela própria linguagem de consultas, SQL, removendo a responsabilidade da aplicação de fazer esses joins. Em Document DBs caso seja necessário fazer um join, as vezes há múltiplos roundtrips ao banco, para trazer dados de dois ou mais documentos, enquanto uma única query SQL pode trazer dados de varias tabelas.
Normalização evita dados duplicados e tira a responsabilidade da aplicação de manter consistência dos dados, que é garantida pelo RDBMS.
Exemplo:
Cliente, Pedidos e Produtos — Modelo Relacional
Exemplo Cliente Pedido Produto - Modelo de Documentos
Com esses exemplos dá pra se ter uma ideia das vantagens e desvantagens de cada modelo descritas acima. Repare que o documento de Pedidos já possui quase todos os dados no mesmo documento, com uma certa duplicação dos dados (dos produtos) e uma "chave estrangeira" para o documento de Clientes, que irá forçar a aplicação a fazer o "join" para obter os dados do cliente.
Já o modelo relacional está bem normalizado, sem duplicação de dados, mas que para obter os dados completos do pedido, é necessário fazer join em outras tres tabelas (Produto, Item Produto e cliente). Porém essa consulta é facilmente executada em somente uma requisição ao banco de dados.
Modelo de Grafos
E se seu modelo de dados tem muitas relações many-to-many? Como esse tipo de relacionamento não é suportado em Document Databases, e ter varias tabelas N-N em um modelo relacional (como a tabela ItemPedido acima), torna o modelo e consultas demasiadamente complexas.
O modelo de grafos nesse caso é bom para isso, onde cada entidade pode estar relacionada com qualquer outra entidade.
“File:Property graph model.png” by М.Оюунболор is licensed under CC BY-SA 4.0
Nesse modelo, entidades, também chamadas de nós ou vertices, e os
relacionamentos são as arestas.
Alguns bons exemplos de uso de Graph Databases:
Social Graph: onde vertices podem ser pessoas interconectadas, locais onde empresas estão localizadas, pessoas fazem checkin, posts que tem comentários, likes, shares, etc.
Modelar isso com um modelo de documentos ou relacional pode ser bem mais dificil do que com um modelo de grafos.
Social Graph
Graph Databases tem uma linguagem de consultas, as mais comuns sendo SparQL, Cypher e Datalog.
Um banco de dados de grafos disponivel abertamente para consultas usando a linguagem SparQL é o Wikidata.
Como escolher o modelo?
Uma estratégia é entender primeiro os requerimentos dos relacionamentos entre as entidades. Se houver relacionamentos many-to-many, Document Databases
provavelmente não vai ser a melhor escolha. Já se houver relacionamentos one-to-many onde os dados podem ficar co-localizados na mesma entidade,
desnormalizados e sem requerimentos rigorosos de consistência, um modelo de documentos pode ser adequado. E se voce verificar que as entidade pode ser relacionar com qualquer outra entidade, grafos podem ser uma boa solução.
originalmente publicado em: https://medium.com/@breno_ferreira/designing-data-intensive-apps-resumo-cap-2-4ddf1d5659a1
Conteúdo sob a licensa CC-BY-NC
Top comments (0)