Hello all,
This week I implemented support for prepared statements and result
renderers. Both features were driven by the need that Ontowiki is
switching to Sparql internally (instead of using direct sql queries),
and sometimes does some hundreds of sparql queries to create one html pag=
e..
Speed is necessary in this case - parsing the sparql queries and
transforming them into native sql takes some time. This time can be
saved if you do 50 queries of the same type, just with different query
values (SELECT ?o { ?s foaf:name ?o }, changing 'foaf:name' every time).
In normal SQL this is done by using prepared statements: replace the
values in your query with '?' question marks (or ":varname" style
variable names), and prepare it. You may execute the statement with
different variable values, greatly speeding it up since query parsing
can be omitted.
The SPARQL standard does not mention prepared statements. Thus, my
implementation is proprietary and extend the standard.
An example of how to use prepared statements can be found in
test/sparqlDb-prepare.php
I benchmarked repeatedly doing 1000 simple queries using normal queries
and using prepared statements. The speedup when using prepared
statements is 400%, taking 3 seconds on average instead of 12 seconds.
Note that this benchmark took place without native prepared statements
support. The problem is that ADODB's mysqli driver does only emulate
prepared statements instead of using mysqli's native functions. If
ADODB's mysqli driver will someday support native sql prepared
statements, or the benchmark would be run on a database whose driver
currently support native sql prepared statements, we would get an even
higher speedup.
Part 2: Result Renderers
Ontowiki internally does not use RAP's object classes for
Resource/Literal/Blank and such but its own optimized classes.
To use RAP's sparql results, the result sets returned by the sparql
engine needed to be converted, causing a the process to be slowed down
by a constant factor.
Since I needed a good way to create XML and HTML results anyway (and
Bartel Pieterse also asked for JSON result support), I developed some
pluggable result renderers. Using them, you can easily create your own
result renderer that converts the raw database results into the format
you desire, without needing to change any of RAPs classes - just pass
your renderer's class or even an renderer object to the query() or
execute() method, and this one is used to create the results.
Currently I implemented three result renderers: The default rap
object/array renderen, HTML and an XML renderer (as specified by
http://www.w3.org/TR/rdf-sparql-XMLres/).
The only thing left is that I still need to implement the same system
for the non-database sparql engine, but that shouldn't be that hard.
My next task is to implement a Sparql Query filter parser, and add
filtering support to SparqlEngineDb.
--=20
Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
Christian Weiske
|
