Grafo

Vários estudos e pesquisas tendo por base modelos de dados baseados em grafos, têm vindo a ser realizados desde os anos 70 (Angles e Gutierrez, 2008). A atividade associada a este modelo e às bases de dados que nele se baseiam, teve o seu momento mais próspero na primeira metade dos anos 90 do século XX, seguido de um quase total abandono e esquecimento por parte do mundo académico e dos seus investigadores (Angles e Gutierrez, 2008). Mais recentemente com a introdução dos primeiros conceitos associados à web 3.0 e aos projetos Linked Data (Berners-Lee et al., 2009), conjugado com a cada vez mais omnipresente cultura das redes sociais, voltou a trazer estas bases de dados para a linha da frente do interesse dos investigadores, quer a um nível académico quer a um nível empresarial.

Neste tipo de bases de dados, o modelo de dados representa uma rede que contém nós, arestas e propriedades (McCreary e Kelly, 2014). As arestas são utilizadas para ligar dois nós e representam uma relação, as relações podem possuir uma direção, conferindo assim um significado à relação. Os nós podem possuir propriedades, estas descrevem com variáveis graus de profundidade os dados contidos nesses nós; arestas também podem possui os seus próprios conjuntos de propriedades. As relações são identificadas pelos seus nomes e podem ser atravessadas em ambas as direções (Kaur e Rani, 2013).

Os sistemas de gestão de bases de dados relacionais utilizam números artificiais como chaves primárias e chaves estrangeiras, de modo a conseguir relacionar linhas que estão em tabelas armazenadas em sectores diferentes de um disco rígido. Operações de agregação de tabelas revelam-se bastante caras em termos de performance nestes sistemas, impulsionado por fatores como a latência e escritas/ leituras de disco (McCreary e Kelly, 2014). Ao contrário das bases de dados relacionais, as bases de dados que recorrem ao armazenamento to tipo grafo,

3.5 Taxonomia das Bases de dados NoSQL

de disco (McCreary e Kelly, 2014). Ao contrário de outros tipos de bases de dados NoSQL, este tipo de bases de dados não possui as mesmas propriedades de escalabilidade por vários servidores. Os dados podem ser replicados por vários servidores de modo a melhorar a performance de leituras e consultas, no entanto escrever dados em vários servidores e realizar consultas a grafos que se estendem por vários nós em diferentes servidores podem revelar-se de complexa e difícil implementação (McCreary e Kelly, 2014). Segundo (Kaur e Rani, 2013) as soluções mais populares representativas deste tipo de bases de dados NoSQL são:

3.5.4.1 Neo4J (Neo-Technology, 2014a)

Uma base de dados NoSQL, disponibilizada pela empresa Neo Technology, esteve em desenvolvimento por uma década antes de a primeira versão alcançar o público em meados de 2010 (Nawroth, 2010). Neo4J é um sistema integrado, baseado em disco, totalmente transacional, desenvolvido em Java, que armazena dados em estruturas de grafos, em vez de tabelas (Vicknair et al., 2010). Este sistema é considerado o líder no âmbito das bases de dados do tipo grafo (Webber, 2012) e isso deve-se, em grande parte, ao seu modelo intuitivo e expressivo, que permite obter dados altamente relacionados. Este sistema é bastante mais rápido do que as bases de dados relacionais, tornando-o ideal para gerir dados complexos em vários domínios (Webber, 2012). Este sistema possui duas versões distintas: uma versão comunitária gratuita e de código aberto, bastante limitada em relação às outras versões, e uma versão empresarial, gratuita para utilizadores individuais, com limitações ao nível da utilização de recursos. Essa mesma versão possui também 2 outros módulos de pagamento aplicáveis, dependendo do tamanho da organização e dos recursos computacionais que a mesma pretenda utilizar. Segundo (Neo-Technology, 2014b) e (Hurwitz et al., 2013) estas são as características mais importantes do sistema Neo4J:

 Intuitivo: utiliza um modelo de grafos para representação dos dados.  Fiável: Suporta transações ACID.

 Rápido e resistente: Utiliza um motor de armazenamento nativo baseado em disco. Possui uma framework transversal poderosa para a realização de consultas de alta velocidade.

 Altamente disponível e massivamente escalável: Quando distribuído por várias máquinas, o sistema pode alcançar milhares de milhões de nós e relações.

 Linguagem de realização de queries: Este sistema suporta uma linguagem declarativa denominada de Cypher, desenhada especificamente para realizar queries sobre grafos e os seus componentes. Esta linguagem é vagamente baseada na sintaxe SQL.

3.5.4.2 Titan (Aurelius, 2014c)

Este sistema é um dos mais recentes projetos a ver a luz do dia, no mundo das bases de dados NoSQL de armazenamento do tipo grafo; foi apresentado ao público em 2012. Como vários dos sistemas deste âmbito, é escrito em Java e é um projeto de fonte aberta. Este sistema é altamente escalável, otimizado para armazenar e realizar consultas sobre grafos que possuam milhares de milhões de nós e arestas, e que possam estar distribuídos por vários conjuntos de máquinas. É uma base de dados transacional capaz de suportar milhares de utilizadores a

3 Bases de Dados NoSQL

realizarem travessias de grafos complexas de forma concorrente (Aurelius, 2014a) e possui uma arquitetura de armazenamento capaz de suportar ligações a outros tipos de bases de dados do tipo par chave-valor ou família de colunas. O sistema suporta ligações a 3 bases de dados em particular: HBase, BerkelyDB e Cassandra. A opção por uma das 3 bases de dados, influenciará de maneira contrastante as propriedades transacionais e de escalabilidade do sistema (Kolomicenko et al., 2013). Essa opção deve reger-se pelos requerimentos e pelas regras do negócio ou projeto em causa.

3.5.4.3 OrientDB (OrienTechnologies, 2014)

Este sistema representa uma base de dados NoSQL de fonte aberta apresentado em meados de 2010 e o seu ponto mais interessante é a sua arquitetura de armazenamento multimodelo. Assim providencia suporte e combinação de 3 tipos de armazenamento diferentes: par-chave valor, colunas e grafos (Kolomicenko et al., 2013). Esta situação permite, por exemplo, que documentos possuam arestas entre eles, assim emulando as propriedades de adjacência de documentos sem recurso a meios de indexação (Barmpis e Kolovos, 2012). As transações neste sistema apresentam suporte completo das propriedades ACID; é possível realizar escritas e leituras concorrentes no mesmo registo, sem necessidade de o sistema bloquear a base de dados. No entanto, todos os registos devem possuir a sua versão para que a idade de um registo seja verificado quando uma transação é realizada. Eventuais conflitos de transações têm de ser resolvidos na lógica da aplicação e não pela base de dados (Kolomicenko et al., 2013).