Embedded Files
FABRICIO MAGNO DE ALMEIDA LEITE¹
JANAÍNA APARECIDA DE FREITAS²
RESUMO
RESUMO
Existe uma gama imensa de bancos de dados disponíveis no mercado hoje. São mais de 30 se for contar somente os utilizados pelas maiores empresas do mercado, sendo esses distribuídos em cinco modelos diferentes no que se refere à estrutura de armazenamento de dados, que influencia diretamente o desempenho da aplicação, o custo de desenvolvimento e manutenção e o custo de escalonamento. Há certos tipos de aplicações em que se torna quase inviável o desenvolvimento, caso haja uma escolha equivocada referente ao tipo de banco de dados a ser utilizado. Este trabalho visa abordar os principais pontos a serem analisados para auxiliar o entendimento das necessidades de determinada aplicação e posteriormente a elaboração de uma modelagem de banco de dados que ajude a aplicação a alcançar a melhor eficiência possível, tanto de processamento quanto de custo-benefício. Para atingir esse objetivo, é explicado através de uma pesquisa bibliográfica, as principais diferenças entre os modelos SQL e noSQL. Dentro do modelo noSQL serão explicadas as diferenças, vantagens e desvantagens de cada um dos 4 tipos: chave-valor, grafo, orientado a documento e orientado a coluna.
PALAVRAS-CHAVE:
PALAVRAS-CHAVE:
Tecnologia; Banco de Dados; noSql; Escalabilidade.
¹Pós-graduando em Banco de Dados pelo Centro Universitário Cesumar – UniCesumar. Graduado em Análise e Desenvolvimento de Sistemas pelo Centro Universitário Cesumar – UniCesumar.
² Mestranda em Ciências da Computação pela Universidade Estadual de Maringá (UEM). Especialista em Docência no Ensino Superior: Tecnologias Educacionais e Inovação. Especialização MBA em Teste de Software. Graduada em Informática pela Universidade Estadual de Maringá (UEM/2010). Orientadora.
INTRODUÇÃO
INTRODUÇÃO
Com o avanço cada vez maior do uso da tecnologia e novos softwares, têm surgido também novas tecnologias de bancos de dados. Ao se iniciar um projeto de software, é comum surgir dúvida na análise de qual tecnologia utilizar para armazenagem dos dados. Caso essa análise seja feita de forma equivocada a empresa pode arcar com um alto custo de desenvolvimento da aplicação sem necessidade, ou sofrer com isso no futuro quando se notar que é preciso mais robustez, segurança ou velocidade nos dados e o custo de escalabilidade ou manutenção for alto demais.
Apesar dos bancos de dados existentes terem o mesmo objetivo – persistir as informações com segurança – a maneira com que esses dados se estruturam, são armazenados e se correlacionam entre si influenciam a velocidade dos procedimentos realizados no banco de dados, bem como a maneira e custo da escalabilidade caso o volume de dados aumente.
O presente trabalho irá mostrar primeiramente as diferenças entre bancos de dados SQL e noSQL, posteriormente irá explanar os modelos de noSQL existentes e seus principais casos de uso.
Para se alcançar o objetivo do trabalho, realizou-se um levantamento bibliográfico de publicações relativas à ciência de dados, em fontes como periódicos, artigos e sites específicos.
ENTENDENDO OS CONCEITOS E A IMPORT NCIA DA MODELAGEM DE DADOS
ENTENDENDO OS CONCEITOS E A IMPORT NCIA DA MODELAGEM DE DADOS
Segundo Costa (2012), estamos na era das grandes massas de dados, empresas armazenam incontáveis informações, usuários geram dados, sensores geram e trocam dados na internet das coisas e as arquiteturas em nuvem obrigam as organizações a lidarem com um dilúvio de dados que expõem as limitações das soluções tradicionais de armazenamento, gerenciamento, análise e transferência.
Segundo Wanderley (1999), Inteligência de Negócios (também conhecido como Business Intelligence ou simplesmente BI) é um conceito que se associa a processos de coleta de dados, organização dos mesmos e transformação em informação, que, depois de analisada e contextualizada, transforma-se em inteligência para a empresa. Esta, por sua vez, aplicada a processos de decisão gera vantagens competitivas para a organização.
O uso dessa técnica vem crescendo cada vez mais dentro das empresas, com isso, cresce a necessidade de se trabalhar com massas de dados e os desafios que a acompanham. Segundo Magnus (2018) o primeiro desafio que podemos considerar é o tratamento dos dados primários, que na maioria dos casos não estão prontos e estruturados, sua lapidação pode ser um grande desafio dependendo da sua origem e características.
Com esse cenário, vemos uma das grandes necessidades de uma eficiente modelagem de dados e tecnologia para seu armazenamento. Muller (1999) declara que a modelagem de dados é o primeiro passo no projeto do banco de dados porque ela fornece a ligação entre as necessidades do usuário e a solução de software que o atende.
Em relação à modelagem de um banco de dados, precisamos primeiramente pensar no esquema do banco de dados. Chyi (2014) explica que o esquema do banco de dados é a estrutura do armazenamento dos dados, que descreve o tipo e estrutura do modelo lógico, os tipos de entidades e os relacionamentos entre as mesmas. Se a modelagem não for bem realizada, corre-se o risco de escolher um modelo de banco de dados que não atende corretamente à aplicação.
SQL E NOSQL
SQL E NOSQL
Para Sharma e Dave (2012), SQL é um sistema de gerenciamento de banco de dados relacional. NoSQL significa “não apenas SQL”, é um sistema de gerenciamento de banco de dados não relacional, usado para armazenar uma quantidade enorme de dados. Erven (2015) declara que o crescente volume de dados em estruturas distintas e a necessidade de gerar informação rapidamente vem forçando o estudo de novos modelos de dados além do relacional.
Sharma e Dave (2012) ressaltam que os bancos de dados relacionais são projetados para serem executados em uma única máquina, por isso, precisamos de uma máquina grande para dimensionar. Já os bancos de dados noSQL segundo Strauch (2011) são projetados para escalabilidade horizontal e não precisam de alta disponibilidade de hardware, máquinas podem ser adicionadas, removidas e até falharem sem necessitar do mesmo esforço que seria empregado em bancos relacionais.
De Souza (2014) explica que os bancos noSQL não utilizam a álgebra relacional e nem possuem linguagem de consulta nativa SQL, o que torna mais complexo o desenvolvimento. Normalmente os bancos noSQL possuem estrutura simplificada, sem estrutura de relacionamentos e com suporte natural à replicação.
A partir dessa análise, conclui-se que os bancos de dados noSQL são dinâmicos e se encaixam bem em vários tipos de aplicação, se destacando do modelo SQL principalmente em aplicações com um grande volume de dados ou dados dinâmicos, e devido à sua escalabilidade e velocidade.
Eu acho um equívoco migrar de um modelo de dados relacional [..] sem ter um racional muito claro. [...] Ao optar por um modelo relacional, você acaba se beneficiando ao se aproveitar de mais de 20 anos de investimento em ferramentas, automação, frameworks e conhecimento público (MEYRELLES, 2015, online).
As análises citadas acima por Meyrelles (2015) mostram uma visão interessante dessa comparação, ressaltando que o modelo relacional tem benefícios devido à sua maturidade. De acordo com a DB-Engines (2020), os bancos de dados relacionais mais utilizados hoje são: Oracle, MySQL e Microsoft SQL Server.
MODELOS DE BANCOS DE DADOS NOSQL
MODELOS DE BANCOS DE DADOS NOSQL
Os bancos de dados noSQL são categorizados pela maneira e estrutura com que armazenam seus dados, podendo ser esse um dos quatro modelos: chave-valor, grafo, orientado a documento e orientado à coluna. Cada um desses modelos atende melhor determinado tipo de necessidade de armazenamento, leitura ou escrita. É necessário, portanto, conhecer bem esses modelos bem como a necessidade da aplicação.
O modelo de banco de dados baseado em chave-valor funciona como um dicionário, onde há uma chave qualquer para cada registro.
Um banco de dados chave-valor armazena dados como um conjunto de pares de chave-valor em que uma chave funciona como um identificador exclusivo. A chave e os valores podem ser qualquer coisa, desde objetos simples até objetos compostos complexos. Bancos de dados de chave-valor são altamente particionáveis e permitem escalabilidade horizontal que outros tipos de bancos de dados não conseguem alcançar (AMAZON, 2020, online).
Diferentemente de um banco de dados relacional, um banco de dados de chave-valor tem uma estrutura dinâmica, onde cada valor pode ter a informação que o usuário desejar.
Figura 1 - Representação de como funciona a estrutura de registro do Amazon DynamoDB
Fonte: Amazon (2020)
A imagem acima representa o funcionamento do esquema do banco de dados Amazon DynamoDB, famoso banco de dados chave-valor da Amazon. Todos os bancos de dados chave-valor seguem esse mesmo modelo no armazenamento.
Para Moniruzzaman e Hossain (2013), a simplicidade desse modelo de armazenamento o faz ideal para recuperação extremamente rápida e escalável de valores necessários para tarefas como gerenciamento de perfis de usuários, sessões a se recuperar ou nomes de produtos. A Amazon faz uso extensivo de seu próprio banco de dados chave-valor Amazon DynamoDB em seu carrinho de compras.
De acordo com a DB-Engines (2020), os bancos de dados noSQL chave-valor mais utilizados hoje são: Redis, Amazon DynamoDB e Memcached.
Em relação ao modelo de banco de dados baseado em grafo, Penteado (2014, p. 1) nos diz que: “O banco de dados em grafos surgiu como uma alternativa ao banco de dados relacional para dar suporte a sistemas cuja interconectividade de dados é um aspecto importante”.
Para Rocha (2013), um grafo G = (V,E) consiste em um conjunto finito V de vértices e um conjunto finito E de arestas onde cada elemento E possui um par de vértices. Um grafo pode ser representado visualmente, com cada vértice sendo um círculo, e cada aresta sendo representada por uma linha que liga os dois vértices (círculos) aos quais a aresta está associada.
Com os vértices (também chamados de nós) e suas arestas, nós conseguimos representar complexos sistemas de dados vinculados entre si, conforme mostra a imagem abaixo:
Figura 2 - Representação de como funciona a estrutura de registros no banco de dados de Grafo
Fonte: Adaptado de Penteado (2014, p. 5).
Nos bancos de dados grafo, o cruzamento das associações ou dos relacionamentos ocorre muito rapidamente, uma vez que os relacionamentos entre os nós não são calculados no momento das consultas, mas persistem no banco de dados. Os bancos de dados gráficos são vantajosos em casos de uso como redes sociais, mecanismos de recomendação e detecção de fraudes, em que é necessário criar relacionamentos entre os dados e consultar rapidamente esses relacionamentos (AMAZON, 2020, online).
Conforme a citação acima explica, quando o vínculo entre os muitos registros é tão importante ou até mais que o próprio registro, o banco de dados em grafo se torna uma excelente escolha. De acordo com a DB-Engines (2020), os bancos de dados noSQL baseados em grafo mais utilizados hoje são: Neo4j, Microsoft Azure CosmosDB, OrientDB e Virtuoso.
Em relação ao modelo de banco de dados orientado a documento, Ritchie (2013) afirma que os mesmos não utilizam esquemas fixos, mas sim semiestruturas de dados conhecidas como documentos. Essas estruturas podem conter qualquer número de campos e tamanhos. Cada documento é independente e contém todo o conteúdo que uma determinada entidade necessita. Geralmente esses documentos são representados pela notação de objeto JavaScript (JSON).
Ritchie (2013) também cita que o formato JSON adiciona flexibilidade devido ao seu esquema livre. Isso permite que o sistema se desenvolva sem precisar forçar os registros existentes a serem reestruturados, facilitando na evolução da estrutura dos dados e customização.
Manoj (2014) ressalta que os bancos de dados orientados a documento são indicados para aplicações em que os dados não precisam ser armazenados em uma tabela com campos de tamanho uniforme, mas, em vez disso, os dados devem ser armazenados como um documento com características especiais, mas em contra partida, esse modelo de banco de dados deve ser evitado se os registros precisarem ter muitas relações entre si e normalização.
Harrison (2010) destaca que a estrutura do modelo orientado a documento pode trazer problemas na integridade dos dados devido ao fato de algumas informações ficarem duplicadas em vários documentos. Esse modelo facilita o desenvolvimento pois a estrutura em que o documento é armazenada é muito parecida com a estrutura orientada a objeto utilizada pelas linguagens de programação modernas, com isso o documento pode ser mapeado quase que diretamente para uma classe da linguagem de programação, enquanto que o registro que vem de um banco de dados relacional precisa passar por um tratamento para ser mapeado para uma classe durante o desenvolvimento.
Figura 3 - Exemplo de um registro no banco de dados orientado a documento
Fonte: Adaptado de Amazon (2020).
A imagem acima representa um documento em formato JSON em um banco de dados orientado a documentos. Pode se ver que todas as informações dos filmes estão contidas dentro desse documento, cada filme não faz vínculo a outros registros para recuperar dados que são comuns a vários filmes, como diretores por exemplo. De acordo com a DB-Engines (2020), os bancos de dados noSQL orientados a documentos mais utilizados hoje são: MongoDB, Amazon DynamoDB, Microsoft Azure Cosmos DB e Couchbase.
Por fim, temos o modelo de banco de dados orientado a coluna, que segundo Strauch (2011), os mesmos armazenam e processam seus dados por colunas em vez de linhas, essa abordagem tem sua origem na análise e inteligência de negócios, onde o processamento compartilhado pode ser usado para criar aplicativos de alto desempenho.
Segundo o site Database.Guide (2016), esse modelo de armazenamento se destaca ao utilizar comandos de agregação como SUM, COUNT e AVG. Também se destaca pela velocidade em ler uma enorme quantidade de registros e também pelo fato de ser escalado e distribuído facilmente.
De Souza (2014) afirma que neste modelo os dados são indexados por uma tripla (linha, coluna e timestamp), onde linhas e colunas são identificadas por chaves e o timestamp permite identificar versões diferentes de um mesmo dado. Outro conceito associado a esse modelo é o de família de colunas que é usado com o intuito de agrupar colunas que armazenam o mesmo tipo de dados.
Rahien (2010) cita que apesar de semelhanças entre esse modelo e o modelo relacional, eles são bem diferentes. Além de um modelo guardar os dados em linhas e o outro em colunas, há outras diferenças que fazem com que seja impossível aplicar a mesma solução utilizada em um banco relacional, em um banco de dados orientado à coluna.
Figura 4 - Representação de como funciona a estrutura de registro do banco de dados orientado a coluna
Fonte: Database.Guide (2016).
A imagem acima representa os elementos que compõem a estrutura do banco de dados orientado a colunas. Temos as linhas que podem conter diferentes números de colunas. Cada coluna é contida somente dentro de sua linha e não se estende para outras linhas como em um banco de dados relacional. Cada coluna contém um nome (chave), um valor associado e um timestamp que fornece a data e hora para diferenciar diferentes versões da mesma informação. (Database.Guide, 2016). De acordo com a DB-Engines (2020), os bancos de dados noSQL orientados à coluna mais utilizados hoje são: Cassandra, HBase e Datastax Enterprise.
USO EM CONJUNTO DE VÁRIOS MODELOS
USO EM CONJUNTO DE VÁRIOS MODELOS
Em soluções mais complexas é interessante e comum se utilizar mais de um modelo de banco de dados, como por exemplo em uma arquitetura CQRS.
Command Query Responsibility Segregation (CQRS), que é caracterizado por separar a arquitetura em dois grandes modelos: um, de leitura, denominado de queries, e outro, de escrita, denominado commands. Com esta separação, é possível fornecer a estes sistemas de larga escala uma forma de conseguirem equilibrar a carga (FERREIRA, 2012, p. 2).
A imagem abaixo representa um sistema de e-commerce que utiliza 4 modelos de bancos de dados diferentes, um para cada tipo de necessidade da aplicação.
Figura 5 - Representação de um sistema que utiliza 4 modelos de bancos de dados
Fonte: Sadalage e Fowler (2013).
Sadalage e Fowler (2013) comentam a imagem acima explicando que um sistema de comércio eletrônico possui muitos dados temporários que não pertencem ao armazenamento principal. Por exemplo, um carrinho de compras e dados de sessão são temporários, que se ajustam melhor a um banco noSQL do tipo chave-valor. Já os pedidos concluídos e o gráfico social do cliente se ajustam melhor em modelos orientado a documento baseado em grafo, respectivamente. Por fim, o estoque e o preço dos itens têm um ajuste melhor em um sistema relacional.
CONSIDERAÇÕES FINAIS
CONSIDERAÇÕES FINAIS
Foram apresentadas as principais diferenças dos tipos de bancos de dados SQL e noSQL, os quais vêm ganhando cada vez mais espaço no mercado devido às suas características de escalabilidade, velocidade e praticidade melhores dependendo da modelagem dos dados. Junto com as diferenças foi exposto que o modelo relacional é ainda o mais usado, mais fácil de se implementar em aplicações com esquema definido e com maior informação disponível na rede devido a sua maturidade.
Destrinchamos os modelos noSQL existentes hoje, explicando primeiramente sobre o chave-valor, que é um modelo que utiliza um dicionário de chaves e valores que podem ser qualquer coisa, com grande escalabilidade e velocidade, além da praticidade de trabalhar grandes listas e com dados brutos sem esquema definido. Em seguida foi apresentado o modelo baseado em grafo que utiliza a teoria dos grafos para armazenar as informações e principalmente o vínculo das mesmas, possui foco em trazer grandes interligações de dados de forma bastante eficiente. Chegando no modelo orientado a documento que é composto por uma coleção de documentos que não possui esquema definido e pode conter quaisquer informações de uma entidade em um único documento, o que torna rápida a consulta dessas informações. E por último o modelo orientado a coluna que é uma mistura do tipo chave-valor e relacional, possui informações chave-valor, porém agregadas em colunas e tabelas, destaque no desempenho de consultas agregadas em grandes quantidades de registros.
Diante do exposto, conclui-se que, para obter uma boa modelagem dos dados, é preciso compreender a própria aplicação e suas necessidades, bem como conhecer as tecnologias que o mercado oferece. A boa modelagem é de suma importância para identificar a melhor tecnologia e com isso alcançar a eficácia no sistema, eficácia essa que engloba a velocidade de desenvolvimento, velocidade de trabalho, possível escalonamento no futuro e custo-benefício condizente com o projeto do software.
REFERÊNCIAS
REFERÊNCIAS
AMAZON. O que é um banco de dados de chave-valor?, 2020. Disponível em: <https://aws.amazon.com/pt/nosql/key-value/>. Acesso em: 21 mar. 2020.
AMAZON. O que é um banco de dados gráfico?, 2020. Disponível em: <https://aws.amazon.com/pt/nosql/graph/>. Acesso em: 15 maio. 2020.
CHYI, Wong Aun. User-guided Database Schema Generation For Naive Database Developers. 2014
COSTA, Luıs Henrique MK et al. Grandes Massas de Dados na Nuvem: Desafios e Técnicas para Inovaçao. 2012.
DATABASE.GUIDE. What is a Column Store Database?, 2016. Disponível em: <https://database.guide/what-is-a-column-store-database/>. Acesso em: 21 mar. 2020.
DE SOUZA, Alexandre Morais et al. Critérios para Seleção de SGBD NoSQL: o Ponto de Vista de Especialistas com base na Literatura. Anais do X Simpósio Brasileiro de Sistemas de Informação, p. 149-160, 2014.
ERVEN, Gustavo Cordeiro Galvão van. MDG-NoSQL: modelo de dados para bancos NoSQL baseados em grafos. 2015.
FERREIRA, Carlos Miguel Brites da Silva. Padrão CQRS para sistemas distribuídos de larga escala. 2012.
HARRISON. NoSQL and Document-Oriented Databases, 2010. Disponível em: <http://www.dbta.com/Columns/Notes-on-NoSQL/NoSQL-and-Document-Oriented-Databases-72035.aspx>. Acesso em: 22 mar. 2020.
MAGNUS. Inteligência de Negócios: entenda o que é BI, como usar e quais as tendências para o futuro, 2018. Disponível em: <https://transformacaodigital.com/dados/inteligencia-de-negocios-entenda-o-que-e-bi-como-usar-e-quais-as-tendencias-para-o-futuro/>. Acesso em: 28 mar. 2020.
MANOJ, V. Comparative study of nosql document, column store databases and evaluation of cassandra. International Journal of Database Management Systems, v. 6, n. 4, p. 11, 2014.
MEYRELLES. Uma gentil introdução ao uso de banco de dados orientados a grafos com Neo4j, 2015. Disponível em: <https://medium.com/accendis-tech/uma-gentil-introdu%C3%A7%C3%A3o-ao-uso-de-banco-de-dados-orientados-a-grafos-com-neo4j-ca148df2d352>. Acesso em: 28 mar. 2020.
MULLER, Robert J. Database design for smarties: using UML for data modeling. 1999.
MONIRUZZAMAN, A. B. M.; HOSSAIN, Syed Akhter. Nosql database: New era of databases for big data analytics-classification, characteristics and comparison. arXiv preprint arXiv:1307.0191, 2013.
PENTEADO, Raqueline RM et al. Um estudo sobre bancos de dados em grafos nativos. X ERBD-Escola Regional de Banco de Dados, 2014.
RAHIEN. Column (Family) Databases, 2010. Disponível em: <http://ayende.com/blog/4500/that-no-sql-thing-column-family-databases>. Acesso em: 23 mai. 2013.
RITCHIE, Brian. RavenDB high performance. 2013.
ROCHA, Roberto Ribeiro. Algoritmos de Particionamento e Banco de Dados Orientado a Grafos. 2013.
SADALAGE, Pramod J.; FOWLER, Martin. NoSQL Essencial: Um guia conciso para o Mundo emergente da persistência poliglota. 2019.
SHARMA, Vatika; DAVE, Meenu. Sql and nosql databases. International Journal of Advanced Research in Computer Science and Software Engineering, v. 2, n. 8, 2012.
STRAUCH, Christof; SITES, Ultra-Large Scale; KRIHA, Walter. NoSQL databases. Lecture Notes, Stuttgart Media University, v. 20, p. 24, 2011.
WANDERLEY, Ana Valéria Medeiros. Um instrumento de macropolítica de informação. Concepção de um sistema de inteligência de negócios para gestão de investimentos de engenharia. Ciência da informação, v. 28, n. 2, p. 190-199, 1999.
Page updated
Report abuse