Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Someone asked an ominously similar question on the <a href="http://boards.openlinksw.com/support/viewtopic.php?f=12&amp;t=6022&amp;start=0" rel="nofollow">OpenLink Support forums</a> a few days ago are you the same person ?</p> <p>What is the reason for wanting to split this large RDF graph (more than 100GB), how much does that equate to in terms of triples ?</p> <p>There is a <a href="http://docs.openlinksw.com/virtuoso/clusteroperation.html" rel="nofollow">Virtuoso Clustered Edition</a> available in commercial form only enabling multiple Virtuoso instances spread across multiple physical instances and/or machines to pool there resources for processing large volumes of data RDF or other ie SQL etc. That way you don't have to physically split graphs you simply load the data into the clustered instance and it will be automatically partitioned for you and you query as if a single Virtuos instance, with good locality which is the key to performance.</p> <p>Virtuoso also supports the standard <a href="http://www.w3.org/2009/sparql/docs/fed/service" rel="nofollow">SPARQL-FED</a> syntax for distributed query execution as detailed on the W3C web site, using the "service" clause to perform the remote execution and return the result via your local Virtuoso instance. Thus a sample query query executing a remote query against the DBpedia SPARQL endpoint from a local Virtuoso instance would be:</p> <blockquote> <p>SELECT * WHERE { SERVICE <a href="http://dbpedia.org/sparql" rel="nofollow">http://dbpedia.org/sparql</a> {<br> SELECT * WHERE<br> {<br> ?s ?p ?o . FILTER (?s = <a href="http://dbpedia.org/resource/Nevis" rel="nofollow">http://dbpedia.org/resource/Nevis</a> ) } LIMIT 100<br> }<br> }</p> </blockquote> <p>Thus the data could be split across multiple single server instance (open source or commercial or other with sparql-fed support) and queried, but you would have to split the graph yourself manually and the performance of SPARQL-FED generally it not very good as you loose locality and the internal optimisations of a "true" clustered server solution ...</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload