The use of ontologies for knowledge representation in several areas has become increasingly common. One of the reasons for the growing interest in using these structures is the capacity of knowledge representation and reasoning, especially when there is a high amount of data. However, few papers reffer to persistence and management of this kind of data, mostly focusing on modeling aspects. That being said, the motivation of this paper is to extend the research related to the persistence of this kind of data. For this, performance tests were made to compare the AllegroGraph, GraphDB, MarkLogic, Stardog, and Virtuoso tools using the WatDiv benchmark. In the tests performed, the Virtuoso tool presented the best performance in the vast majority of the queries, considering one, five, and ten milion triples. Resumo. A utilizac¸ a˜o de ontologias para representac¸ a˜o de conhecimento em diversas a´reas vem sendo cada vez mais comum. Um dos motivos para o crescente interesse no uso dessas estruturas e´ a capacidade de se realizar infereˆncia no conhecimento armazenado, derivando novo conhecimento, especialmente quando a quantidade de dados e´ alta. Entretanto, observa-se pouca atenc¸a˜o relacionada a` forma de se persistir e gerenciar esses dados, sendo as pesquisas mais focadas em sua modelagem. Desta forma, este artigo tem como motivac¸a˜o ampliar a pesquisa relacionada a persisteˆncia destes dados. Para isso, foram realizados testes de desempenho visando comparar as ferramentas AllegroGraph, GraphDB, MarkLogic, Stardog e Virtuoso utilizando o benchmark WatDiv. Nos testes realizados a ferramenta Virtuoso apresentou o melhor desempenho na grande maioria das consultas considerando um, cinco e dez milho˜es de triplas.
Um dos diversos exemplos da utilizac¸ a˜o de ontologias para a modelagem de
dados e´ a modelagem de contexto de alunos para auxiliar um ambiente de aprendizagem
ub´ıqua (u-learning) [
Objetos de Aprendizado1, necessitando de um modelo ontolo´gico para acompanhar os
mesmos ao longo de seu ciclo de vida [
Embora diversas propostas apresentadas neste aˆmbito fac¸am uso de tais
informac¸o˜es, poucas versam sobre a maneira de garantir a persisteˆncia das
mesmas [
Percebe-se ainda que alguns trabalhos utilizam reposito´rios relacionais para tal fim
[
O modelo de armazenamento em triplas pode ser dividido em treˆs categorias com
base na arquitetura de sua implementac¸ a˜o: em memo´ria; nativo; e externo. No
armazenamento em memo´ria, todo o conjunto de triplas e´ mantido na memo´ria principal do
dispositivo para manipulac¸a˜o, o que o torna ineficiente quando o volume de dados e´ grande
[
O modelo de armazenamento nativo fornece persisteˆncia com o uso de uma base
de dados projetada para esta funcionalidade. As ferramentas que implementam este
modelo oferecem seus pro´prios recursos de manipulac¸a˜o da base de dados, utilizando
linguagens como a SPARQL para acessa´-lo. Na categoria de armazenamento externo, as triplas
sa˜o persistidas, por exemplo, em bases relacionais, as quais na˜o sa˜o apropriadas para o
armazenamento de triplas [
Nota-se que o armazenamento nativo de triplas possui um bom desempenho, melhorando a capacidade de racioc´ınio do sistema como um todo, e proporcionando assim uma base de dados apropriada para o modelo de triplas (RDF) [BioOntology 2011]. Apesar disso, poucos trabalhos presentes na literatura tratam efetivamente sobre a persisteˆncia e a manipulac¸a˜o dos dados provenientes de ontologias, sendo que a manipulac¸a˜o eficiente desses dados tem impacto direto nos servic¸os oferecidos, podendo tornar o processo de tomada de decisa˜o mais eficiente.
Visando contribuir para a pesquisa na a´rea, este artigo apresenta uma ana´lise de desempenho de cinco ferramentas populares para armazenamento nativo de triplas: AllegroGraph, GraphDB, MarkLogic, Stardog e Virtuoso. Com base nesta ana´lise sera´ poss´ıvel identificar aquela mais apta para ser utilizada em sistemas que dependem de informac¸o˜es provenientes de ontologias.
Para realizar a ana´lise de desempenho foi utilizado o benchmark WatDiv [Aluc¸ 2014], o qual disponibiliza um nu´mero diverso de consultas para teste, possibilitando uma ana´lise criteriosa das ferramentas. Os experimentos foram realizados em duas 1Unidade de instruc¸a˜o/ensino reutiliza´vel. Podem ser definidos por ”qualquer entidade, digital ou na˜o digital, que possa ser utilizada, reutilizada ou referenciada durante o aprendizado suportado por tecnologias”. dimenso˜es, na primeira foi analisada a escalabilidade de cada ferramenta, considerando diferentes tamanhos da base de dados. Na segunda os desempenhos fornecidos pelas ferramentas foram comparados entre si. O objetivo do experimento e´ o de identificar a ferramenta que apresenta a melhor relac¸a˜o entre escalabilidade e desempenho.
O restante do artigo esta´ dividido como segue. A Sec¸a˜o 2 apresenta trabalhos relacionados ao gerenciamento de dados no formato de triplas. A Sec¸a˜o 3 versa sobre as ferramentas de gerenciamento de dados nativas em formato de triplas, mostrando um breve resumo sobre as cinco ferramentas analisadas. A Sec¸a˜o 4 mostra o benchmark WatDiv, enquanto a Sec¸a˜o 5 apresenta a ana´lise de desempenho das ferramentas com este benchmark. Por fim, sa˜o apresentadas as considerac¸o˜es finais e os trabalhos futuros na Sec¸a˜o 6.
Os trabalhos de [Bizer and Schultz 2009] e [Aluc¸ 2014] apresentam propostas de benchmarks para ferramentas de gerenciamento nativo em formato RDF, utilizando consultas na linguagem SPARQL para medir os tempos de execuc¸a˜o de diversas ferramentas. Os dois trabalhos apresentam resultados de ana´lises de desempenho utilizando os benchmarks propostos em diversas ferramentas de armazenamento em triplas. Pore´m, devido ao fato de que o principal objetivo destes trabalhos e´ apresentar os benchmarks propostos, e´ dado pouco foco a` ana´lise de desempenho em si, sendo dada mais atenc¸a˜o a apresentac¸ a˜o das caracter´ısticas te´cnicas dos benchmarks. Ale´m disso, como os artigos em questa˜o foram escritos na e´poca do lanc¸amento de seus benchmarks, diversas das ferramentas de armazenamento apresentadas neles esta˜o atualmente obsoletas ou possuem verso˜es mais atuais.
Em [
Em [
Dois dos trabalhos relacionados identificados, [
Ja´ o trabalho de [
Dito isso, este trabalho possui o diferencial de tratar especificamente de uma ana´lise de desempenho de ferramentas de gerenciamento de triplas para suporte a racioc´ınio e infereˆncia. Esta ana´lise e´ baseada no tempo de execuc¸a˜o de diferentes consultas SPARQL, sendo analisadas cinco ferramentas populares para gerenciamento de triplas. Ademais, e´ apresentado uma validac¸a˜o dos resultados com o uso de um teste estat´ıstico.
Os bancos de dados de armazenamento nativo em triplas foram constru´ıdos para o
armazenamento e recuperac¸ a˜o de dados no formato RDF. Para a ana´lise desenvolvida, foram
escolhidas cinco ferramentas para armazenamento nativo de triplas, com base
principalmente em sua popularidade. As cinco ferramentas escolhidas esta˜o entre as dez primeiras
no ranking da
AllegroGraph [Allegrograph 2019] e´ uma estrutura de banco de dados e aplicac¸a˜o de alto desempenho para o armazenamento e consulta de dados no formato de triplas. Pode ser implantada como um servidor de banco de dados independente e oferece interfaces para acesso remoto, onde a comunicac¸a˜o entre os processos de servidor e cliente e´ realizada pela Web.
GraphDB (antigamente conhecido como OWLIM) [Graph
O benchmark escolhido para os testes desenvolvidos neste artigo foi o Waterloo SPARQL Diversity Test Suite (WatDiv), desenvolvido pela Universidade de Waterloo [Aluc¸ 2014]. Dentre os principais crite´rios de escolha deste benchmark, destacam-se os diferentes tipos de consulta disponibilizados e o fato de ele ser baseado realmente em triplas. Desta forma, permitindo que o benchmark identifique problemas de desempenho sobre ferramentas de gerenciamento de triplas existentes que na˜o sa˜o detectados por outros benchmarks. O WatDiv fornece um gerador de datasets com um fator de escala varia´vel, permitindo assim a gerac¸a˜o de datasets de diversos tamanhos.
Acompanha o pacote do benchmark um gerador de consultas SPARQL. As consultas sa˜o geradas em quatros grupos: “Lineares” (L), mais simples e diretas; “Estrela” (S) consultas que referenciam diversos nodos em um formato de estrela; “Floco de Neve”(F), consultas que referenciam va´rios nodos que por sua vez referenciam outros nodos; e “Complexas” (C), consultas que utilizam uma mistura dos formatos anteriores. Ao todo sa˜o disponibilizadas vinte consultas, as quais sa˜o divididas entre os grupos da seguinte forma: cinco Lineares; sete Estrelas; cinco Flocos de neve; e treˆs Complexas.
A Figura 1 apresenta um exemplo de consulta do tipo Linear, mostrando a consulta L1 em seu formato grafo e em sua representac¸a˜o SPARQL. Ja´ na Figura 2, e´ apresentado um exemplo de uma consulta do tipo Estrela, apresentando a consulta S1, tambe´m em suas formas de grafo e de consulta SPARQL. Por sua vez, a Figura 3 mostra um exemplo de consulta do tipo Floco de neve, mostrando a consulta F2 tambe´m em seu formato de grafo e representac¸a˜o SPARQL. Por fim, a Figura 4 apresenta um exemplo de consulta do tipo Complexa, mostrando a consulta C2 tanto em seu formato de grafo quanto em sua representac¸a˜o SPARQL.
(a) L1 em formato de grafo
(b) L1 SPARQL
Figura 1. Exemplo de consulta do tipo Linear
E´ importante observar que variac¸ o˜es no tamanho de uma base RDF na˜o devem refletir significativamente no desempenho de seu acesso. O mesmo na˜o e´ va´lido para as diferenc¸as de tempo de acesso entre consultas pertencentes aos diferentes grupos.
Para realizac¸ a˜o da ana´lise das ferramentas apresentadas na Sec¸ a˜o 5, foram gerados datasets com 1, 5 e 10 milho˜es de triplas, os quais foram inseridos nas cinco ferramentas analisadas. Com o intuito de analisar o desempenho das ferramentas optou-se pela execuc¸a˜o de doze consultas, sendo treˆs de cada grupo.
(a) S1 em formato de grafo
(b) S1 SPARQL
Figura 2. Exemplo de consulta do tipo Estrela (a) F2 em formato de grafo
(b) F2 SPARQL
Figura 3. Exemplo de consulta do tipo Floco de neve
Desta forma, considerando todos os valores permitidos para cada varia´vel, teria-se um conjunto de 180 estudos de caso, cada um representado por Pi = (d; f; c), onde: d: informa o tamanho do dataset utilizado (1, 5 ou 10 milho˜es); f : identifica a ferramenta utilizada (Alegrograph, GraphDB, Stardog, Virtuoso e
MarkLogic); c: informa a consulta utilizada, sendo treˆs de cada grupo ( Linear - L1, L4 e L5, Estrela - S2, S5 e S7, Floco de neve - F2, F4 e F5 e Complexa - C1, C2 e C3 ) Devido a limitac¸o˜es de sua licenc¸a gratuita, os testes com 10 milho˜es de triplas na˜o foram realizados na ferramenta AllegroGraph. Com isso, ha´ duas possibilidades para d (1, 5), cinco para f e doze para c, mais os executa´veis de quatro ferramentas para d com valor de 10 milho˜es. Desta forma, chega-se ao total de P = fP1; P2; :::P168g executa´veis. Cada combinac¸a˜o dos valores permitidos foi executada 30 vezes, desta forma, permitindo realizar a ana´lise dos dados coletados com uma maior precisa˜o. Assim, foram coletados 168 30 = 5040 tempos de execuc¸o˜es individuais.
(a) C2 em formato de grafo (b) C2 SPARQL
Figura 4. Exemplo de consulta do tipo Complexa
Os tempos me´dios de execuc¸ a˜o em segundos para cada tipo de consulta, “Lineares” (L), “Estrela” (S) ,“Floco de Neve”(F) e “Complexas” (C) sa˜o apresentados na respectivamente nas figuras 5, 6, 7 e 8.
Figura 5. Tempo de execu c¸a˜ o das consultas do tipo L.
Os desempenhos com a ferramenta MarkLogic na˜o sa˜o apresentados pois, ale´m de ter um desempenho muito inferior a`s demais ferramentas, o desvio padra˜o se apresentou muito elevado.
Com os resultados apresentados, e´ poss´ıvel concluir que a ferramenta Virtuoso apresentou os melhores resultados de desempenho na grande maioria das consultas. Tambe´m e´ poss´ıvel observar que as ferramentas Virtuoso e Stardog apresentaram boa escalabilidade, com baixa variac¸a˜o de tempo de execuc¸ a˜o entre os diferentes tamanhos de base de dados, enquanto que as ferramentas AllegroGraph e GraphDB apresentaram uma escalabilidade tambe´m boa, pore´m inferior as duas ferramentas anteriormente mencionadas.
Esta conclusa˜o foi validada aplicando o teste t de Student com intervalo de confianc¸a de 95% entre as cinco ferramentas, em cada um dos 3 tamanhos e em cada Figura 6. Tempo de execu c¸a˜ o das consultas do tipo S.
Figura 7. Tempo de execu c¸a˜ o das consultas do tipo F. uma das 12 consultas. Como resultados destes testes foram detectados que os resultados da consulta C1 com o tamanho 5M entre Stardog e AllegroGraph e entre Stardog e GraphDB na˜o obtiveram diferenc¸as estat´ısticas significativas. Ainda, a consulta C3 para o tamanho 1M entre Stardog e GraphDB tambe´m na˜o obteve diferenc¸as estat´ısticas significativas. Os demais resultados apresentaram diferenc¸as estat´ısticas significativas, assegurando os resultados obtidos e apresentados nas figuras 5, 6, 7 e 8.
Tambe´m pode ser notado que o Stardog obteve resultados muito similares em todos os testes realizados, tendo sido a ferramenta com menor alterac¸a˜o de desempenho entre tamanhos diferentes de base de dados. Ale´m dos testes entre as ferramentas, foi analisado se o tamanho da base impactava no desempenho das mesmas. Para isso, foi realizado o teste t entre as me´dias de execuc¸a˜o de cada ferramenta comparando o tamanho
Figura 8. Tempo de execu c¸a˜ o das consultas do tipo C. 1M com 5M e 5M com 10M.
As consultas que na˜o apresentaram diferenc¸as significativas sa˜o apresentadas na Tabela 1. Pode-se observar que a ferramenta AllegroGraph foi a que apresentou menor n u´mero de consultas com diferenc¸as na˜o significativas. No entanto, relembra-se que nesta ferramenta na˜o foi poss´ıvel realizar consultas em uma base de tamanho de 10M. A ferramenta que apresentou maior n u´mero de diferenc¸as na˜o significativas foi a MarkLogic, pois ale´m de apresentar tempos de execuc¸a˜o altos, tambe´m apresentou valores muito altos para os desvios padr o˜es anotados.
Embora o motivo de a ferramenta Virtuoso ter apresentado os melhores desempenhos em todos os testes na˜o tenha sido um foco do trabalho, uma hip o´tese bastante prova´vel para este fato e´ sua estrate´gia de armazenamento em qua´drupla. Com essa estrate´gia, a ferramenta armazena na˜o apenas a tripla ba´sica (sujeito, predicado, objeto) mas tambe´m o grafo relacionado da mesma. O armazenamento deste grafo permite que o Virtuoso acesse o mesmo diretamente quando deseja realizar uma consulta, fazendo com que o tempo para a construc¸a˜o do mesmo, gasto pelas demais ferramentas, seja economizado.
Tabela 1. Consultas que na˜ o apresentaram diferen c¸as significativas
Com a ana´lise dos testes realizados, e´ poss´ıvel constatar que a ferramenta que apresenta a melhor escalabilidade em relac¸ a˜o tanto ao tamanho da base de dados quanto as diferentes consultas foi a Stardog. Pore´m, destaca-se que apesar da ferramenta Virtuoso variar um pouco mais que a Stardog, ela obteve os melhores resultados na grande maioria dos testes realizados, sofrendo pouca variac¸ a˜o no desempenho com o aumento no tamanho da base de dados.
Este trabalho realizou, primariamente, uma identificac¸a˜o de ferramentas para armazenamento de dados em formato de triplas, um formato altamente apropriado para o armazenamento de dados ontolo´gicos. Em conjunto, o trabalho tambe´m realizou uma comparac¸a˜o de desempenho relacionada ao tempo de execuc¸a˜o de consultas SPARQL entre cinco ferramentas de armazenamento em formato de triplas: AllegroGraph, GraphDB, MarkLogic, Stardog e Virtuoso. Foi apresentada uma descric¸a˜o de cada ferramenta analisada e tambe´m do benchmark utilizado para a execuc¸a˜o dos testes, o WatDiv. Os testes consideraram o tempo de execuc¸ a˜o, em segundos, de doze diferentes consultas em treˆs tamanhos de bases de dados.
Ao fim dos testes foi poss´ıvel concluir que a ferramenta Virtuoso foi a que mostrou o melhor desempenho geral, apresentando o tempo de execuc¸a˜o mais baixo na grande maioria das consultas, apesar de apresentar uma flutuac¸a˜o no desempenho um pouco maior que Stardog quando varia-se a quantidade de dados tratada.
Estes resultados foram importantes nas deciso˜es de pesquisa a serem tomadas pelo grupo, pois forneceram embasamento para a escolha da ferramenta mais adequada para gerenciar o modelo de triplas implementado no middleware para Computac¸a˜o Ub´ıqua desenvolvido pelo grupo. Esta escolha impacta diretamente nos servic¸os cientes de contexto oferecidos, pois as aplicac¸ o˜es enviam continuamente requisic¸o˜es de consulta aos contextos gerenciados pelo middleware para sua tomada de decisa˜o, sendo importante se ter o menor tempo poss´ıvel de acesso aos dados. Ale´m disso, a identificac¸ a˜o e a utilizac¸a˜o da ferramenta de armazenamento adequada para as ontologias utilizadas pelo grupo afetam diretamente a capacidade de realizar infereˆncia nas mesmas, facilitando e agilizando a tarefa.
Como trabalhos futuros destaca-se a continuidade da pesquisa ligada a provimento de servic¸os cientes de contexto, aplicando a ferramenta Virtuoso para acesso aos dados do modelo de triplas. Onde esta ferramenta sera´ utilizada para gerenciar a persisteˆncia dos dados providos pela ontologia utilizada em um ambiente u-learning, utilizando tambe´m uma estrate´gia de aprendizado multimodelo.
O presente trabalho foi realizado com apoio da Coordenac¸a˜o de Aperfeic¸oamento de Pessoal de N´ıvel Superior - Brasil (CAPES) - Co´digo de Financiamento 001 e da FAPERGS (Programa Pesquisador Gau´cho - PqG).
Allegrograph (2019). Acesso em maio 2019. Dispon´ıvel em: franz.com/agraph/ allegrograph/.
Aluc¸, G. (2014). Diversified Stress Testing of RDF Data Management Systems. Master’s thesis, David R. Cheriton School of Computer Science, Waterloo, ON, Canada. Behr, A., Primo, T., and Viccari, R. (2016). Towards educational metadata interoperability on semantic web. In Brazilian Symposium on Computers in Education (Simpo´sio Brasileiro de Informa´tica na Educac¸a˜o-SBIE), volume 27, page 1026.
BioOntology (2011). Comparison of Triple Stores. Dispon´ıvel online em: <https:// www.bioontology.org/wiki/images/6/6a/Triple_Stores.pdf>. acesso em novembro 2016.
Bizer, C. and Schultz, A. (2009). The berlin sparql benchmark.