From OntologPSMW

Jump to: navigation, search
[ ]

Contents

Optimized SPARQL performance management via native API     (1A)

Team: Victor Chernov (MSK, UTC+4) vchernov at nitrosbase.com (lead), Vladislav Golovkov (MSK, UTC+4) vgolovkov at nitrosbase.com     (1A2)

Post-event updates     (1A3)

Optimized SPARQL performance management via native API Hackathon took place on March 29, 2014 14:00 - 18:00 MSK (virtual session) with subsequent activities during the next day.     (1A3A)

Four people participated in the event:     (1A3B)

  1. Victor Chernov (team lead), General Manager at NitrosData Rus, Russia, vchernov@nitrosbase.com;     (1A3C)
  2. Vladislav Golovkov System Architect at NitrosData Rus, Russia, vgolovkov@nitrosbase.com;     (1A3D)
  3. Andrej Andrejev, Ph.D. student at Uppsala University, Sweden, andrej.andrejev@it.uu.se;     (1A3E)
  4. Vladimir Salnikov, Head of QA Department at Compile Group, Russia, vladimir.salnikov@compilesoft.ru.     (1A3F)

During the event triplestores have been installed, benchmark queries prepared, experiments have been set up and run. The results are discussed and published (see link below).     (1A3G)

The main conclusions are:     (1A3H)

  1. Performance is bottleneck for ontological technologies.     (1A3I)
  2. It is desirable to have direct access to database, not through TCP protocol.     (1A3J)
  3. Sometimes it is worth to simplify the queries as much as possible and make some processing on the client.     (1A3K)
  4. Very often what is difficult to do with a single large query is easy to implement with a set of small ones. In those cases triplestore should be able to perform small queries quickly. Further performance gain could be reached giving the users direct access to database, bypassing SPARQL processing.     (1A3L)
  5. The myth that RDF database is slower than SQL does not work anymore. RDF storages perform fast and can compete with SQL databases.     (1A3M)

The report can be downloaded from     (1A3N)


Event announce     (1A4)

Participation: You are welcome to participate, please send an E-mail to vchernov at nitrosbase.com.     (1A4A)

Event starts 29th of March 2014 14:00 MSK / 10:00 UTC / 03:00 PST all over the world     (1A4B)

Communication:     (1A4C)

  1. Google Hangout - We'll connect you according to participant's E-mail;     (1A4D)
  2. Skype - Will be used as additional tool if the number of Google Hangout connections exceeded. Please add vladislav.golovkov to your Skype contact list.     (1A4E)

A Caveat Concerning the IPR Policy Conformance:     (1A4F)


The Goals of the project are     (1A4H)

Studying the kinds of queries revealing the advantages of one or another RDF database. The goals imply:     (1A4I)

  • Selection of a SPARQL subset from SP2Bench     (1A4J)
  • Forming a dataset and loading it to all triple-stores.     (1A4K)
  • Implementing measurement aids, testing     (1A4L)
  • Accurate time measurement, getting min, max, average and median times.     (1A4M)
  • Reflection on the results, advantages and disadvantages of the triplestores on each selected query.     (1A4N)

The following triplestores will be compared:     (1A4O)

The triplestores have the following important advantages:     (1A4S)

It is important to use native API for fast query execution. All 3 tools provide native API:     (1A4W)

Virtuoso     (1A4X)
Jena, Sesame and Virtuoso ODBC RDF Extensions for SPASQL     (1A4Y)
Stardog     (1A4Z)
the core SNARL (Stardog Native API for the RDF Language) classes and interfaces     (1A4AA)
NitrosBase     (1A4AB)
C++ and .NET native API     (1A4AC)

We suppose writing additional codes needed for accurate testing:     (1A4AD)

The following steps are needed for loading test dataset:     (1A4AJ)

Note: Data are considered as loaded as soon as the system is ready to perform a simplest search query. This is done to eliminate background processes (eg. indexing).     (1A4AM)

We are going to explore the query execution performance by the databases under consideration (Virtuoso, Stardog, NitrosBase).     (1A4AN)

The queries should be fairly simple and cover the different techniques, for example:     (1A4AO)

Note: During testing each database may allocate a lot of resources, that can affect the performance of other databases. That��s why each test should be stared from system reboot.     (1A4AX)


This page has been migrated from the OntologWiki - Click here for original page     (1A4AY)