CHECKLIST PARA AUXILIAR NA DEFINIÇÃO DA ARQUITETURA DE BANCO DE DADOS

Transcrição

1 CHECKLIST PARA AUXILIAR NA DEFINIÇÃO DA ARQUITETURA DE BANCO DE DADOS Tiago Vanderlinde, Osmar Oliveira Braz Junior Universidade do Estado de Santa Catarina - UDESC tiago.vanderlinde@gmail.com, osmar.oliveira.braz@gmail.com Resumo Este trabalho apresenta a definição de um checklist que auxilia a escolha da arquitetura de banco de dados para uma determinada aplicação. Através deste checklist é possível determinar três arquiteturas de banco de dados diferentes: modelo relacional, NoSQL ou persistência poliglota, que utiliza o modelo relacional e NoSQL. A escolha de uma destas arquiteturas é feita através de alguns critérios, e para isso, são elencados as características de cada aplicação e posteriormente confrontados com estes critérios. Desta forma, é possível determinar qual é a arquitetura mais indicada para cada aplicação. Palavras-chave: Checklist. Arquitetura. Banco de Dados Abstract This work presents the definition of a checklist that assists the choice of database architecture for a given application. Through this checklist is to identify three architectures from different databases: relational model, NoSQL or polyglot persistence, which uses the relational model and NoSQL. The choice of these architectures is done by certain criteria, and so are the characteristics listed for each application and then confronted with these criteria. This way, you can determine which is the most suitable architecture for each application. Keywords: Checklist. Architecture. Database. 1. Introdução Atualmente está cada vez mais comum o surgimento de aplicações que possuem uma grande quantidade de dados. O Google, por exemplo, precisa lidar com grandes quantidades de dados diariamente. Estima-se que, no ano de 2009, cerca de 20 petabytes de informação era processado diariamente pela Google (HLIP apud ISSA, 2011). Outro caso onde o processamento de dados é elevado é no Ebay, a empresa americana de comércio eletrônico, possui um Data Warehouse de 5 petabytes, que é utilizado para armazenar dados sobre seus clientes, produtos e as transações realizadas em sua plataforma (TERADATA apud ISSA, 2011). Em casos como estes, existiu uma grande necessidade de construir sistemas distribuídos, devido essa grande massa de dados. Entretanto também existe uma grande dificuldade em manter sistemas deste porte utilizando uma arquitetura de banco de dados baseada no modelo relacional. Nestes exemplos as aplicações tiveram problemas com a utilização de bancos de dados relacionais e tiveram que mudar para outro modelo de persistência. Desta forma, começou a surgir outros tipos de bancos de dados denominados NoSQL (ISSA, 2010). O termo NoSQL foi utilizado pela primeira vez em 1998, por Carlo Strozzi, para identificar bancos de dados de código aberto que não possuíam interface SQL (NVRSDQEF apud ISSA, 2010). A partir deste momento começou a surgir um movimento para que os bancos de dados NoSQL fossem difundidos e utilizados no desenvolvimento de aplicações. Atualmente, este movimento vem crescendo bastante no ambiente de desenvolvimento de software, e a adoção e difusão de tecnologias NoSQL vem se tornando algo cada vez mais comum. Uma parte desta adoção vem sendo utilizada em locais onde os bancos de dados tradicionais ainda são fortemente dominantes como, por exemplo, instituições financeiras,

2 agências governamentais, e comércio de produtos de varejo. Isto pode ser explicado pelo fato que existe uma demanda muito grande para soluções que tenham alta flexibilidade, escalabilidade, performance, e suporte a diferentes modelos de dados complexos (VIEIRA et al, 2012). Entretanto, grande parte dos bancos de dados NoSQL que são considerados não relacionais foram desenvolvidos com a ideia de que, por melhor que um banco de dados seja, ele não servirá para todos os casos. Assim, dependendo da demanda exigida, os bancos de dados NoSQL podem ser uma alternativa eficiente ao modelo relacional. (LEITE, 2010). Outra arquitetura que vem ganhando espaço é a persistência poliglota (Polyglot Persistence). Nestes casos, uma aplicação pode ter mais de um banco de dados. Assim, a informação da aplicação fica particionada e acaba sendo armazenada em bancos de dados que utilizam tecnologias diferentes. Desta forma, podem-se tratar os problemas individualmente e utilizar o banco dados mais adequando para cada tipo de problema (FOWLER, 2011). Um problema com a utilização da persistência poliglota é a complexidade da aplicação, que acaba aumentando. Assim, acaba-se tornando necessária a quebra do código fonte em componentes separados que interagem entre si. Apesar de este modelo ter um custo de desenvolvimento maior, ele tem suas vantagens. Afinal enquanto os bancos de dados relacionais são usados de forma inadequada, este modelo acaba proporcionando maior flexibilidade na definição da arquitetura de banco de dados e auxiliando uma parte significativa do desempenho da aplicação (FOWLER, 2011). Conforme Leite (2010) e Fowler (2011), bancos de dados NoSQL foram desenvolvidos para atender situações específicas. Assim, começa a surgir alguns questionamentos: Quando utilizar banco de dados relacionais e quando utilizar banco de dados NoSQL? Quando é devemos utilizar os dois? Essas são as principais dúvidas que este trabalho pretende explorar. Para tanto, serão apresentados critérios para avaliação de aplicações, e posteriormente confrontados com as características de cada aplicação. Estes critérios vão auxiliar a tomada de decisão, escolhendo o modelo de persistência mais adequado para cada aplicação. Mesmo definindo a escolha de um banco de dados NoSQL ainda pode existir dúvidas de qual o tipo de banco de dados utilizar. Afinal, existem vários tipos de banco de dados NoSQL, por exemplo: orientado a documento, chave-valor, colunar, grafos. Diante disso, este trabalho vai apresentar conceitos de banco de dados NoSQL, critérios para avaliação do modelo de persistência a ser adotado nas aplicações e ainda aplicação prática destes critérios em um estudo de caso. 2. Objetivos Desenvolver um modelo que auxilie a tomada de decisão na definição da arquitetura da aplicação, escolhendo uma destas arquiteturas de banco de dados: modelo relacional, NoSQL ou persistência poliglota. Criar um checklist que contenha critérios de avaliação, para que seja possível auxiliar na definição da melhor arquitetura de banco de dados para cada aplicação. Efetuar a aplicação deste checklist em um estudo de caso, para verificar se o resultado obtido é aderente à aplicação. 3. Metodologia Para a realização deste projeto é fundamental a utilização de metodologia de pesquisa com a descrição dos procedimentos a serem utilizados. Neste tópico encontram-se as metodologias utilizadas neste projeto.

3 Um método de pesquisa utilizada nesse trabalho é a pesquisa bibliográfica. Para Severino (2007), este tipo de pesquisa constitui em informações extraídas a partir de um material já elaborado, composto principalmente de livros, artigos científicos e demais trabalhos. A principal vantagem deste tipo de pesquisa é que se pode pesquisar uma gama de assuntos bem maior do que pesquisar diretamente. Assim, a elaboração da fundamentação teórica deste trabalho terá como base principal bibliografias e artigos. No caso das definições dos critérios de avaliação das aplicações também serão utilizados como base bibliografias e artigos. Nestes casos, será necessário efetuar uma compilação das técnicas que foram utilizadas para a escolha de cada tipo de banco de dados, ou seja, os critérios que os autores utilizaram para definir arquitetura de um banco de dados servirão de base para a definição dos critérios que estarão no checklist desenvolvido neste trabalho. Com o checklist de avaliação definido, será efetuado um teste de conceito, ou seja, será utilizado este modelo para avaliação de um estudo de caso e verificar se resultado é coerente. 4. Justificativa Uma aplicação pode ter várias características, e somente uma arquitetura de banco de dados pode não atender a todas. Com o surgimento dos bancos de dados NoSQL e as suas várias frentes acabou aumentando bastante as possibilidades de atender essas situações específicas. O intuito deste trabalho é auxiliar esta tomada de decisão, apresentando critérios que irão categorizar cada uma das arquiteturas de banco de dados. Desta forma, ao final será possível utilizar o checklist desenvolvido neste trabalho para determinar qual é o modelo de dados mais indicado para cada aplicação. 5. Trabalhos correlatos Existem algumas publicações que já falam sobre NoSQL, teorema de CAP e efetuam uma análise comparativa entre os SGBDs relacionais e bancos de dados NoSQL. Um destes trabalhos chama-se Análise Comparativa do Teorema de CAP Entre Banco de Dados NoSQL e Banco de Dados Relacionais e foi desenvolvido por Gleidson Sobreira Leite. Este trabalho tem como foco apresentar um comparativo entre os bancos de dados NoSQL e relacional, baseado no teorema de CAP. Além disso, este trabalho apresenta uma análise mais especifica comparando características as características do teorema de CAP entre banco de dados PostgreSQL e CouchDB. Outro trabalho correlato é a Bancos de Dados NoSQL x SGBDs Relacionais: Análise Comparativa e foi desenvolvido por Ricardo W. Brito. Assim como o anterior este trabalho tem como foco apresentar um comparativo entre os bancos de dados NoSQL e relacional, baseado no teorema de CAP. Entretanto neste comparativo é apresentado de maneira mais específica como cada banco (SGBD relacional e NoSQL) reage no momento de testar as características do teorema CAP. Os dois trabalhos citados acima apresentam um comparativo entre SGBD relacional e NoSQL. Entretanto nenhum deles apresenta de maneira explícita em que momento deve-se utilizar um modelo ou outro. Outro fato é que os dois autores apresentam um comparativo e em nenhum momento sugerem um modelo híbrido, utilizando os dois modelos dentro de uma mesma aplicação. Desta forma, este trabalho pretende apresentar de maneira mais concreta como definir um modelo de persistência de dados para a aplicação. Considerando ainda a possibilidade de utilizar mais de um tipo de arquitetura de banco de dados em uma mesma aplicação.

4 6. Fundamentação teórica O resultado do checklist elaborado neste trabalho é a escolha entre três arquiteturas de bancos de dados diferentes: modelo relacional, NoSQL ou persistência poliglota. Desta forma, são apresentados conceitos de cada uma destas arquiteturas Modelo relacional O modelo relacional é hoje o principal modelo de dados utilizado em aplicações comerciais de processamento de dados. Ele conquistou este destaque devido sua simplicidade, pois, comparado aos modelos anteriores, ele facilita o trabalho no momento de desenvolver aplicações (SILBERSCHATZ, 2006). Segundo Silberschatz (2006), um banco de dados relacional consiste em um conjunto de tabelas, sendo que, cada uma tem um nome atribuído. Enquanto que uma linha de uma tabela representa uma relação entre um conjunto de valores, ou seja, uma tabela é um conjunto de entidades e uma linha é uma entidade. O modelo relacional tem como base a teoria dos conjuntos e álgebra relacional, e foi resultado de um estudo teórico realizado por Codd, que era investigador da IBM. Este modelo foi publicado em 1970, entretanto só foi implementado nos anos 80 e revelou-se ser o mais flexível e adequado ao solucionar os vários problemas que se colocam no nível da concepção e implementação da base de dados (TAKAI, 2005). Para Takai (2005), a estrutura fundamental do modelo relacional é a relação entre tabelas. Uma relação é constituída por um ou mais atributos de uma tabela. Este modelo implementa estruturas de dados organizadas em relações. Porém, para trabalhar com essas tabelas, algumas restrições precisaram ser impostas para evitar aspectos indesejáveis, como: Repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves e integridade de junções de relações NoSQL O NoSQL é um termo genérico usado para se referir a qualquer armazenamento de dados que não segue o modelo relacional especificamente, assim, estes bancos não utilizam o SQL como linguagem de consulta. Este termo normalmente é usado para se referir aos bancos de dados que tentam solucionar os problemas de como: escalabilidade e disponibilidade (VAISH, 2013). O objetivo dos bancos de dados NoSQL é de propor soluções alternativas ao uso do modelo relacional, tendo como um dos principais motivos à estrutura pouco flexível utilizada nos bancos de dados relacionais. Vários projetistas de bancos de dados de grandes organizações passaram a desenvolver novas maneiras de desenvolvimento onde seria possível flexibilizar certas estruturas e regras existentes nos bancos de dados relacionais. Desta forma, em 1998 surgiu o termo NoSQL (Not only SQL) a partir de uma solução de banco de dados que não disponibilizava uma interface SQL, e, posteriormente esse termo passou a representar soluções caracterizadas como uma alternativa ao já bastante utilizado e consolidado modelo relacional (BRITO apud LEITE, 2010). Uma das principais vantagens dos bancos de dados NoSQL sobre os bancos de dados relacionais é a questão do escalonamento. Basicamente pelo fato de que estes bancos foram criados para esse fim, enquanto os SGBDs relacionais possuem uma estruturação menos flexível e menos adaptada para cenários em que o escalonamento faz-se necessário (BRITO, 2013). Bancos de dados NoSQL são subdivididos pelo seu núcleo, ou seja, a maneira com que cada um lida com as informações que armazena. Brito apud Leite (2010) categoriza-os da seguinte forma:

5 Chave-valor; Orientados a documentos; Orientados a colunas; Baseados em grafos; A seguir é apresentado cada uma destas categorias Chave-Valor Dentre os modelos do NoSQL, os bancos de dados chave-valor são considerados os mais simples. Esta categoria é estruturada basicamente por um conjunto de chave-valor, ou seja, um HashMap na linguagem de programação Java. Desta forma, este modelo oferece uma grande eficiência no momento da busca dos dados (TIWARI, 2011). Leavitt apud Issa (2011), apresenta a implementação deste modelo na Amazon, utilizando o banco de dados SimpleDB. Este banco prove funções de indexação de informação e buscas na web 2.0. E ainda uma interface simples para persistência e acesso as dados. Figura 1 Tabela chave-valor (TERMEHCHY apud ISSA, 2011) A figura 1 apresenta um exemplo de tabela chave-valor. As chaves deste modelo são únicas e cada chave aponta para um conjunto de valores. Entretanto as consultas destes valores só podem ser efetuadas pela chave, ou seja, não é possível efetuar a busca de um registro utilizando um de seus valores (VAISH, 2013) Orientados a documentos Bancos de dados orientados a documentos tratam-se de modelos que organizam os dados em coleções. Sendo que estas coleções podem conter um conjunto diversificado de documentos. Isto significa que em uma coleção, os valores dos registros não são delimitados por colunas, dando mais liberdade que os modelos relacionais (TIWARI, 2011). A maioria dos bancos de dados deste modelo utiliza o XML, JSON, BSON ou YAML como maneira de acesso aos dados. Normalmente utilizando o protocolo HTTP com RESTful ou o protocolo Apache Thrift para que as linguagens de programação consigam acessar os dados (VAISH, 2013).

6 Figura 2 Exemplo de documento (VAISH, 2013) A figura 2 apresenta o exemplo de um documento. Neste caso, é apresentado um documento com informações de locais de trabalho. Assim temos o código e o nome do local e após informações sobre o seu endereço. Este modelo pode proporcionar uma alta flexibilidade, pois cada documento pode ter uma estrutura totalmente diferente (VAISH, 2013) Orientados a colunas Os bancos de dados orientados a coluna armazenam os dados em colunas em vez de linhas, como é o caso do modelo relacional. No modelo relacional os dados são apresentados em tabelas bidimensionais compreendendo de linhas e colunas, sendo que, este modelo recupera e processa os dados uma linha de cada vez. Enquanto que o modelo orientado a coluna armazena os dados em forma de colunas (VAISH, 2013). No modelo orientado a colunas, o valor de cada coluna (atributo) é armazenado em sequência, aumentando a performance da leitura de uma única coluna. Com este modelo de armazenamento, o banco de dados carrega em memória apenas os valores das colunas que serão utilizadas, evitando preencher a memória com dados que não serão utilizados (ISSA, 2011). Figura 3 Diferença entre dados no modelo relacional e orientado a colunas (Adaptado de VAISH, 2013)

7 A figura 3 apresenta um exemplo de organização dos dados no modelo relacional e no modelo orientado a colunas. Neste exemplo pode-se perceber que os dados são armazenados em colunas e não em linhas como é no modelo relacional Baseados em grafos Bancos de dados baseados em grafos representam uma categoria especial de bancos de dados do NoSQL, onde as relações são representadas na forma de grafos. Neste modelo, pode haver várias ligações entre os dois nós em um grafo, representando as múltiplas relações que os dois nós compartilham. As relações representadas podem incluir as relações sociais entre as pessoas, ligações de transporte entre lugares, ou topologias de rede entre sistemas conectados (VAISH, 2013). Figura 4 Exemplo de grafo (VAISH, 2013) A figura 4 apresenta um exemplo de grafo. Neste modelo os relacionamentos dos nós são organizados em uma estrutura arbitrária, permitindo um grafo se assemelhar a uma lista, uma árvore, um mapa ou uma entidade composta. Bancos de dados baseados em grafos são bastantes novos no mercado, com apenas algumas soluções comprovadas: Neo4j e FlockDB (utilizado pelo Twitter) (VAISH, 2013) Persistência Poliglota (Poliglot Persistence) A persistência poliglota ou Poliglot Persistence representa uma aplicação que pode ter mais de um banco de dados. Desta forma, durante o seu desenvolvimento foi utilizada mais de uma tecnologia para a persistência dos dados da aplicação. Com isso, podem-se tratar problemas individualmente e utilizar o banco dados mais adequando para cada tipo de situação (FOWLER, 2011). Neste caso a arquitetura de banco de dados pode ficar mais complexa, pois, em uma mesma aplicação podem-se encontrar os vários modelos de bancos de dados NoSQL juntamente com um modelo relacional. Assim, torna-se necessária a quebra do código fonte em componentes separados que interagem entre si. Apesar destes custos este modelo acaba tornando-se viável, pois quando os bancos de dados relacionais são usados de forma inadequada, eles acabam consumindo uma parte significativa do desempenho da aplicação (FOWLER, 2011).

8 Figura 5 Exemplo do modelo híbrido (MCMURTRY et al., 2013) A figura 5 apresenta um exemplo de utilização deste modelo. Neste exemplo é utilizada uma técnica de implementação comum, onde é disponibilizado um serviço de web como uma fachada. O serviço web fornece uma interface que expõe as operações de negócios e as converte em operações que se comunicar com o banco de dados apropriado (MCMURTRY et al, 2013). 7. Checklist Neste tópico será abordada a definição do checklist que auxiliará na tomada de decisão no momento da escolha da arquitetura de banco de dados de uma aplicação. O modelo definido neste tópico apresenta como saída uma das arquiteturas apresentada anteriormente: modelo relacional, NoSQL (chave-valor, orientado a colunas, orientado a documentos, baseado em grafos) ou persistência poliglota. Para tanto, este checklist terá critérios que serão definidos com base em algumas referências bibliográficas. Assim, o primeiro critério que será levado em consideração é o teorema de CAP. Eric Brewer desenvolveu o teorema de CAP (Consistency, Availability e Partition Tolerance), onde ele afirma que é impossível uma aplicação com banco de dados distribuído garantir, de forma simultânea, consistência, disponibilidade e tolerância a partições. Segundo esse teorema, um sistema distribuído pode garantir apenas duas dessas três características simultaneamente (BRITO, 2013). Este conceito surgiu devido às aplicações estarem cada vez maiores, e, com suas bases de dados crescendo exponencialmente, começou a surgir à necessidade de escalar o banco de dados. Entretanto escalar um banco de dados relacional pode ser bastante custoso e/ou complexo. Diversas alternativas ao modelo relacional surgiram para suprir as restrições relativas à complexidade ao realizar a distribuição de dados, das quais a que mais ganhou destaque foi o paradigma NoSQL (Not only SQL) (LEITE, 2010). Segundo Redmond et al (2012), o teorema de CAP prova que somente é possível criar um sistema com banco de dados distribuído consistente e tolerante a partições ou um sistema que está disponível e tolerante a partições ou então um sistema que consistente e disponível. Desta

9 forma, não é possível criar uma aplicação que é consistente, tolerante a partições e disponível (Vide figura 6). Figura 6 Teorema de CAP (Adaptado de VAISH, 2013) Veira et al (2012), apresenta o significado de cada uma destas características do teorema de CAP: Consistência: objetivo é permitir que transações distribuídas em vários nós, que agem com a semântica de tudo-ou-nada. Quando existir réplicas, elas devem estar sempre em um estado consistente; Disponibilidade: objetivo é manter o sistema sempre disponível, e em caso de falha o sistema deve continuar funcionando com alguma réplica dos recursos indisponíveis; Tolerância a partições: objetivo é manter o sistema operando mesmo no caso de falhas de rede, para isso é dividido o processamento dos nós em grupos que não se comunicam. Desta forma, o teorema de CAP é pertinente quando decidir utilizar um banco de dados distribuído. Baseado neste teorema será identificado os primeiros critérios que irão compor o checklist. Sendo o primeiro, identificar se a aplicação necessita de um ambiente distribuído. Caso exista esta necessidade, é necessário que o questionar quais as características desejadas para esta aplicação: Consistência e tolerância a partições; Disponível e tolerância a partições; ou Consistência e disponível. Conforme apresentado na figura 6, nos casos onde a exigência ocorre para que a aplicação esteja disponível e tenha tolerância a partições o indicado são os bancos de dados NoSQL. Nos casos onde a aplicação exige consistência e tolerância a partições é o mais indicado também são os bancos de dados NoSQL. Enquanto que nos casos onde a consistência e a disponibilidade é o mais importante para a aplicação, o mais indicado são os bancos de dados relacionais. Para os casos de consistência e tolerância a partições e disponível e tolerância a partições é indicado o uso de um banco de dados NoSQL. Entretanto não é definida qual a categoria mais indicada (orientado a documentos, orientado a colunas, baseado em grafos ou chave-valor).

10 Assim, será necessário analisar mais alguns critérios para definir qual a arquitetura de banco de dados mais indicada. Fowler et al (2012), apresenta um exemplo que auxilia a diferenciar qual a arquitetura de bancos de dados é a mais indicada baseada no tipo da aplicação. Figura 7 Banco de dados indicado para cada tipo de aplicação (Adaptado de FOLWER et al, 2012) A figura 7 apresenta qual o modelo de persistência mais indicada para cada tipo de aplicação segundo Fowler et al (2012). Segundo ele, o modelo chave-valor é indicado para os casos onde se deseja ter um acesso rápido na escrita e leitura dos dados. Entretanto não existe a necessidade dos dados serem duráveis ou existir a integridade dos dados. Esta ideia também é apresentada por Finley (2010), pois, segundo ele, quando a latência é importante, é difícil efetuar uma busca ou escrita de dados mais rápida que banco de dados chave-valor. Um ponto negativo deste banco de dados é a necessidade de uma quantidade de memória primária maior, por oferecer o recurso de cache de dados. Para Fowler et al (2012), os bancos de dados relacionais são mais indicados para aplicações que precisam lidar com transações, ou em casos onde a modelagem tabular se encaixa perfeitamente na arquitetura da aplicação. Fowler el al (2012) destaca ainda, que as aplicações que necessitam de muitos relatórios também é indicado o uso de bancos de dados relacionais. O principal motivo destacado por ele é a facilidade de integração que as ferramentas de criação de relatórios possuem com a linguagem SQL. Os bancos de dados orientados a documentos são indicados nos casos onde existe uma grande quantidade de leitura e escrita de dados (FOWLER et al, 2012). Além disso, este tipo de banco de dados é indicado para aplicações onde pode existir uma mudança constante na estrutura dos dados, por exemplo: número de variáveis do objeto, coleções de objetos agrupados. Assim, este tipo de banco de dados pode lidar com mudanças de esquema ao longo do tempo (FINLEY, 2010). Fowler et al (2012), indica o uso de bancos de dados orientados a coluna nos casos onde é necessário efetuar análises em grande escala sobre um grande aglomerado de dados. Este tipo de banco de dados também é indicado em casos onde existe uma grande necessidade de escrita de dados. Bancos de dados baseados em grafos são indicados para os casos onde existe a estrutura de dados da aplicação representa um grafo, por exemplo: relacionamentos entre pessoas, locais, etc. (FOWLER et al, 2012). Considerando as características de cada banco de dados é possível elencar critérios e baseado neles é possível definir um checklist que pode auxiliar na escolha da arquitetura de banco de dados, vide quadro 1.

11 Critério Relacional Documental Chave/Valor Colunar Grafo Necessita de ambiente x x x x distribuído Deve ser tolerante a x x x x partições Integridade dos dados é x x obrigatória Relatórios gerenciais são x importantes Estrutura de dados é em x forma tabular Atributos podem variar x x x x constantemente Utilizo algoritmo baseado x no relacionamento entre minhas entidades Persistência dos dados x x x x sempre deve ser garantida Persistência dos dados não x é vital Necessito de alto x desempenho na escrita e leitura de dados Relacionamentos entre as x x x entidades são muito complexos Integridade referencial é x necessária Redundância de dados é um x problema Memória primária é x x x x problema A maioria das pesquisas é x x x x feita pelo atributo A maioria das pesquisas é x feita pelo identificador Quadro 1 Checklist para auxilio na escolha da arquitetura de banco de dados (Autor, 2014) A primeira coluna do checklist apresentado no quadro 1 representa um critério. As demais colunas representam arquitetura de banco de dados, relacional e os tipos de bancos de dados NoSQL. Os registros marcados com x representam que aquele tipo de banco de dados atende aquele critério. Por exemplo: O critério Integridade dos dados é obrigatória é atendido pelos bancos de dados relacionais e orientados a documentos. Para utilizar o checklist apresentado no quadro 1 basta verificar se o critério apresentado na primeira coluna é relevante para a aplicação. Feito isso, é preciso verificar qual ou quais arquiteturas se encaixam neste critério. Ao final é preciso verificar quais foram as arquiteturas indicadas pelo checklist, para os casos onde for mais de uma arquitetura significa que o modelo mais indicado é o híbrido. Existem critérios neste modelo que são atendidos por mais de uma arquitetura. Desta forma, é preciso ter atenção para não adicionar arquiteturas de banco de dados

12 desnecessariamente, pois cada quanto maior o número de arquiteturas maior é o nível de complexidade da aplicação. No tópico a seguir é apresentada a utilização deste checklist em alguns estudos de casos. 8. Aplicação do checklist Neste tópico será apresentada a arquitetura de banco de dados encontrada por outro autor para uma determinada aplicação. O intuito é aplicar este o checklist apresentado no tópico anterior neste mesmo estudo de caso, após será comparada a arquitetura apresentada no estudo de caso com a arquitetura de banco de dados que o checklist sugerir. O estudo de caso abordado será uma solução apresentada por Nance et al (2013), onde é definida a arquitetura de banco de dados para um e-commerce em sistema distribuído. Segundo Nance et al (2013), uma aplicação e-commerce tem uma grande quantidade de dados temporários que não pertencem a estrutura de um banco de dados relacional. Por exemplo, carrinho de compras, sessão com os dados do usuário, etc. Além disso, os comentários dos clientes e os seus relacionamentos nas redes sociais tendem a ter uma melhor aderência em bancos de dados NoSQL. Assim, numa plataforma e-commerce os dados do carrinho de compras precisam ser escritos e lidos no banco de dados rapidamente, mas não é necessário garantir que estes dados sejam persistidos antes da finalização da compra. Os dados pertinentes aos produtos, categorias, preços, etc. possuem uma estrutura tabular. Enquanto que, os históricos dos pedidos não se enquadram nesta categoria. Já as sugestões de clientes, avaliações de produtos ou recomendações possuem uma estrutura baseada em grafos (NANCE et al, 2013). Para solucionar este problema Nance et al (2013) apresenta uma arquitetura poliglota, sendo que, a aplicação teria quatro tipos de bancos de dados diferentes (vide figura 8). Figura 8 Arquitetura de banco de banco de dados para e-commerce (NANCE et al, 2013) Conforme apresentado na figura 8, cada parte da aplicação possui um banco de dados diferente, tornando uma aplicação com persistência poliglota. Baseado nas informações apresentadas por Nance et al (2013), é possível aplicar estes dados no checklist criado anteriormente. A seguir são apresentados os critérios do checklist se enquadram nesta aplicação e-commerce: Necessita de ambiente distribuído Estrutura de dados é em forma tabular Atributos podem variar constantemente

13 Persistência dos dados sempre deve ser garantida Persistência dos dados não é vital Utilizo algoritmo baseado no relacionamento entre minhas entidades Necessito de alto desempenho na escrita e leitura de dados Pode-se perceber que alguns dos critérios são divergentes, por exemplo: Persistência dos dados sempre deve ser garantida e Persistência dos dados não é vital. Isto ocorreu, pois a aplicação tem estruturas de dados diferentes que devem ser analisadas de perspectivas diferentes. No caso do carrinho de compras a persistência não precisa ser garantida, enquanto que nos casos demais casos sempre é necessário garantir a persistência dos dados. Os critérios relacionados a hardware não foram considerados devido não estarem especificados do trabalho de Nance et al (2013). Avaliando os critérios que se enquadram para esta aplicação pode-se perceber que a arquitetura sugerida pelo checklist é a persistência poliglota, sendo que os tipos de banco de dados indicados são: modelo relacional, chave-valor, grafo e documental. Assim, a arquitetura de banco de dados sugerida acaba ficando parecida com a proposta por Nance et al (2013). 9. Considerações finais Atualmente, está cada vez mais comum a necessidade de lidar com uma grande quantidade de dados e mesmo assim garantir um bom desempenho para a aplicação. A definição da arquitetura de banco de dados está totalmente atrelada a este problema. Para auxiliar na solução deste problema este trabalho propôs a criação de um checklist que auxilia na definição da arquitetura de banco de dados. Para determinar os critérios elencados para fazer parte do checklist foram consideradas as características principais de cada tipo de banco de dados. Entretanto algumas situações podem apresentar a necessidade de critérios mais específicos e que não foram catalogados neste checklist podendo ocasionar divergências entre a arquitetura recomendada e a arquitetura ideal para a aplicação. A aplicação do checklist em um estudo de caso mostrou que os critérios elencados para este estudo de caso foram aderentes. A utilização deste checklist pode se tornar um pouco confusa, pois uma mesma aplicação pode ter características totalmente divergentes. No momento de efetuar a avaliação de uma aplicação pode ser necessário considerar apenas uma parte da aplicação. A utilização deste checklist acaba tornando-se desnecessária para os casos onde a pessoa já possui o conhecimento e experiência em várias arquiteturas de banco de dados. Entretanto pode ser utilizada por pessoas que ainda não possuem um conhecimento mais avançado nas várias arquiteturas de banco de dados existentes. Portanto, todos os objetivos propostos neste trabalho foram atendidos, pois foi criado um checklist que auxilia na definição da arquitetura de banco de dados, que posteriormente foi aplicado em um estudo de caso. Referências BRITO, Ricardo W. Bancos de Dados NoSQL x SGBDs Relacionais:Análise Comparativa. Disponível em: < Bancos%20de%20Dados%20NoSQL.pdf>, Acessado em: 03/06/2013.

14 FINLEY, K. What the heck are you actually using NoSQL for?. Disponível em:< Acessado em: 15/11/2013. FOWLER, Martin. Polyglot Persistence. Disponível em: < >, Acessado em: 03/06/2013. FOWLER, Martin et al. The future is: Polyglot Persistence. Disponível em: < Acessado em: 15/11/2013. ISSA, Felipe G. S. Estudo comparativo entre banco de dados relacionais e banco de dados NoSQL na utilização por aplicações de business intelligence. Disponível em: < Gradua%C3%A7%C3%A3o-Felipe-G.-S.-Issa.pdf>, Acessado em: 03/06/2013. LEITE, Gleidson. S. Análise Comparativa do Teorema de CAP Entre Banco de Dados NoSQL e Banco de Dados Relacionais. Disponível em: < >, Acessado em: 03/06/2013. MCMURTRY, Douglas et al. Data Access for Highly-Scalable Solutions: Using SQL, NoSQL and Polyglot Percistence. Disponível em: < >, Acessado em: 15/11/2013. NANCE C. et al. NoSQL vs RDBMS Why there is room for both. Disponível em: < Acessado em 20/11/2013. REDMOND, Eric et al. Seven Databases in Seven Weeks. p1..0. Texas: Pragmatic Programmers, p. SEVERINO, Antonio Joaquim. Metodologia do trabalho científico. 23 ed. São Paulo: Cortez, SILBERSCHATZ, Abraham. Sistema de banco de dados. 5. ed. Rio de Janeiro: Elsevier, p. TAKAI, O. K. Introdução a banco de dados. Disponível em: < Acessado em: 11/10/2013. TIWARI, Shashank. Professional NoSQL. Indianapolis: John Wiley & Sons, p. VAISH, Gaurav. Getting Started with NoSQL. Birmingham: Packt Publishing, p. VIEIRA, M. R et al. Bancos de Dados NoSQL: Conceitos, Ferramentas, Linguagens e Estudos de Casos no Contexto de Big Data. Disponível em: < >, Acessado em: 03/06/2013.