复杂SPARQL查询-Virtuoso性能提示？_Sparql_Virtuoso

复杂SPARQL查询-Virtuoso性能提示？

sparql

复杂SPARQL查询-Virtuoso性能提示？,sparql,virtuoso,Sparql,Virtuoso,我有一个相当复杂的SPARQL查询，它在并行线程（400个线程）中执行数千次。为了可读性，这里的查询稍微简化了（名称空间、属性和变量都减少了），但复杂性没有改变（联合、图的数量等）。该查询针对4个图形运行，其中最大的包含5561181个三元组 PREFIX graphA: <GraphABaseURI:> ASK FROM NAMED <GraphBURI> FROM NAMED <GraphCURI> FROM NAMED <GraphABaseUR

我有一个相当复杂的SPARQL查询，它在并行线程（400个线程）中执行数千次。为了可读性，这里的查询稍微简化了（名称空间、属性和变量都减少了），但复杂性没有改变（联合、图的数量等）。该查询针对4个图形运行，其中最大的包含5561181个三元组

PREFIX graphA: <GraphABaseURI:>

ASK
FROM NAMED <GraphBURI>
FROM NAMED <GraphCURI>
FROM NAMED <GraphABaseURI>
FROM NAMED <GraphDBaseURI>
WHERE{
   {  
      GRAPH <GraphABaseURI>{
         ?variableA a graphA:ClassA .
         ?variableA graphA:propertyA ?variableB .
         ?variableB dcterms:title ?variableC .
         ?variableA graphA:propertyB ?variableD .
         ?variableL<GraphABaseURI:propertyB> ?variableD .
         ?variableD <propertyBURI> ?variableE
      }
      .
      GRAPH <GraphBURI>{
        ?variableF <propertyCURI>/<propertyDURI> ?variableG .
        ?variableF <propertyEURI> ?variableH
      }
      .
      GRAPH <GraphCURI>{
        ?variableI <http://www.w3.org/2004/02/skos/core#notation> ?variableJ .
        ?variableI <http://www.w3.org/2004/02/skos/core#prefLabel> ?variableK .
        FILTER (isLiteral(?variableK) && REGEX(?variableK, "literalA", "i"))
      }
      . 
      FILTER (isLiteral(?variableJ) && ?variableG = ?variableJ) .
      FILTER (?variableE = ?variableH)
   }
   UNION
   {
       GRAPH <GraphABaseURI>{
          ?variableA a graphA:ClassA .
          ?variableA graphA:propertyA ?variableB .
          ?variableB dcterms:title ?variableC .
          ?variableA graphA:propertyB ?variableD .
          ?variableL<propertyBURI> ?variableE .
          ?variableL <propertyFURI> ?variableD .
       }
       .
       GRAPH <GraphDBaseURI>{
          ?variableM <propertyGURI> ?variableN .
          ?variableM <propertyHURI> ?variableO .
          FILTER (isLiteral(?variableO) && REGEX(?variableO, "literalA", "i"))
       }
       .
       FILTER (?variableE = ?variableN) .

   }
   UNION
   {
       GRAPH <GraphABaseURI>{
          ?variableA a graphA:ClassA .
          ?variableA graphA:propertyA ?variableB .
          ?variableB dcterms:title ?variableC .
          ?variableA graphA:propertyB ?variableD .
          ?variableL<propertyBURI> ?variableE .
          ?variableL <propertyIURI> ?variableD .
       }
       .
       GRAPH <GraphDBaseURI>{
          ?variableM <propertyGURI> ?variableN .
          ?variableM <propertyHURI> ?variableO .
          FILTER (isLiteral(?variableO) && REGEX(?variableO, "literalA", "i"))
       }
       .
       FILTER (?variableE = ?variableN) .
   }
   . FILTER (isLiteral(?variableC) && REGEX(?variableC, "literalB", "i")) .  
}

前缀图形：
问
从命名
从命名
从命名
从命名
在哪里{
{  
图表{
？变量a图形：a类。
？可变图形：不动产A？可变图形B。
？可变数据项：标题？可变数据项。
可变图形：属性b可变。
可变的，可变的。
可变的
}
.
图表{
？变量f/？变量g。
？变量F？变量H
}
.
图表{
变量i？变量j。
可变的，可变的。
过滤器（isLiteral（？variableK）和REGEX（？variableK，“literalA”，“i”））
}
. 
过滤器（isLiteral（？variableJ）和&？variableG=？variableJ）。
过滤器（？variableE=？variableH）
}
联合
{
图表{
？变量a图形：a类。
？可变图形：不动产A？可变图形B。
？可变数据项：标题？可变数据项。
可变图形：属性b可变。
可变的，可变的。
可变的，可变的。
}
.
图表{
？variableM？variableN。
？变量？变量。
过滤器（isLiteral（？variableO）和REGEX（？variableO，“literalA”，“i”））
}
.
过滤器（？variableE=？variableN）。
}
联合
{
图表{
？变量a图形：a类。
？可变图形：不动产A？可变图形B。
？可变数据项：标题？可变数据项。
可变图形：属性b可变。
可变的，可变的。
可变的，可变的。
}
.
图表{
？variableM？variableN。
？变量？变量。
过滤器（isLiteral（？variableO）和REGEX（？variableO，“literalA”，“i”））
}
.
过滤器（？variableE=？variableN）。
}
.FILTER（isLiteral（？variableC）和REGEX（？variableC，“literalB”，“i”））。
}

我不希望有人改变上述查询（当然…）。我发布这个查询只是为了演示复杂性和使用的所有SPARQL结构

我的问题是:

如果我把所有的三元组都放在一个图中，我的性能会有所提高吗？这样我就避免了联合并简化了查询，但是，这在性能方面也会有好处吗

是否有任何类型的索引，我可以建立，他们可以有任何帮助与上述查询？我对数据索引不是很有信心，但是读懂后，我想知道Virtuoso 7的默认索引方案是否适合上述查询。虽然谓词是在上述查询的SPARQL三重模式中定义的，但有许多三重模式没有定义主语或谓词。这可能是性能方面的主要问题吗

也许有一个SPARQL语法结构我不知道，在上面的查询中可能会有很大帮助。你能建议点什么吗？例如，我已经通过删除

STR（）

cast并使用

isLiteral（）

函数改进了性能。你能提出别的建议吗

也许您可以建议过度使用复杂的SPARQL语法结构

请注意，我使用的是基于Ubuntu的Virtuoso开源版本，版本：07.20.3214，版本：2015年10月14日

问候,， Pantelis Natsiavas

第一件事——你的精湛身材早已过时；强烈建议更新到（或更高版本）

当查看一个简化的查询时，优化建议自然会受到限制。但是这里有一些想法，没有特定的顺序

，下面的RDF Performance Tuning文档部分提供了两个备选和/或附加索引，这些索引可能对您的查询和数据有意义。正如您所说，您的一些模式将定义图形和对象，以及未定义的主语和谓语，一些其他索引也可能有意义（例如，
```
GOPS
```
，
```
GOSP
```
），这取决于一些其他因素
根据原始加载后数据的变化程度，使用此SQL命令（可以通过任何SQL接口（iSQL、ODBC、JDBC等）重建自由文本索引可能是值得的-

例如，可以产生比

regex（）

过滤器更好的性能-

FILTER (isLiteral(?variableO) && REGEX(?variableO, "literalA", "i")) .

-与-

?variableO bif:contains "'literalA'" .
FILTER ( isLiteral(?variableO) ) .

有助于查询优化工作。这些输出的大部分用于开发分析，因此对您来说可能意义不大，但将其提供给开发人员仍然可以产生有用的建议
出于多种原因，
```
rdf:type
```
谓词（由于SPARQL/Turtle语义糖，通常表示为
```
a
```
）可能是性能杀手。从图形模式中删除这些谓词可能会大大提高性能。如果需要，还有其他方法可以限制解决方案集（例如，通过测试仅由您所需的
```
rdf:type
```
实体拥有的属性），这些方法不会对性能产生负面影响

（免责声明：生产并雇佣我。）

?variableO bif:contains "'literalA'" .
FILTER ( isLiteral(?variableO) ) .