I'm wondering what I should expect for performance of an Oracle triple
store sitting behind TBC/L.
I've been running a simple test. One nice thing about an Oracle triple
store is that you can query it using standard SQL. So I've run three tests
multiple times with the same results.
Background: I'm querying a single Oracle model (graph) that contains about
65 million triples. The comparison is between the length of time it takes
to execute the query in different ways using Oracle directly and going
through the Oracle connector in TBC.
TEST NUMBER 1:
1. Connect directly to Oracle using SQLPlus from my PC.
2. Issue the following query:
SELECT COUNT(s)
FROM TABLE(SEM_MATCH(
'{?s rdf:type ariel:ArielRegulation .}',
SEM_Models('arieldev'),
null,
SEM_ALIASES(SEM_ALIAS('ariel','http://ontologies.pg.com/ariel#'),
SEM_ALIAS('rdf', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#')),
null));
Note the use of the "SEM_MATCH" procedure to issue the SPARQL query. The
query simply counts the number of instances of the class
"ArielRegulation". The answer is 3,942,425.
TEST NUMBER 2:
1. Open the Oracle connector file in TBC from the same PC.
2. Using the Oracle -> Execute SQL menu option, execute the EXACT SAME SQL
query as TEST NUMBER 1.
TEST NUMBER 3:
1. Using the same Oracle connector file in TBC as in TEST NUMBER 2,
execute the following SPARQL version of the same query from the SPARQL
query window in TBC.
PREFIX ariel: <http://ontologies.pg.com/ariel#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT COUNT(?s)
WHERE
{?s rdf:type ariel:ArielRegulation}
RESULTS:
The following illustrates the time it takes to execute the same query using
the different methods described above:
TEST NUMBER 1 - direct Oracle connection - 14 seconds
TEST NUMBER 2 - same SQL query via TBC - 14 seconds
TEST NUMBER 3 - SPARQL version of the same query using TBC and Oracle
connnector/Jena adaptor: 152 seconds
The net is that the same query is TEN TIMES SLOWER going through TBC to
Oracle versus directly. I would expect some performance hit but not a
factor of 10.
Does anyone know if this experience is typical? Does anyone have any "test
queries" that will elucidate specific performance issues? More testing is
certainly needed.
Thanks for your input,
Tim
--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight,
SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.