Merck / Merck/Halyard

Improve SPARQL query optimization by using selectivity

Open
#70 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Java
Stars
114
Forks
18
PR merge metrics
No merged PRs in 30d

Description

SPARQL query optimization in Halyard is based on cardinalities pre-computed by Halyard Stats. A frequent case in SPARQL queries is to encounter triple patterns with similar cardinality, but drastically different selectivity (see e.g., here for a description of selectivity). Selectivity can be considered as the ratio of distinct predicate values to all values (i.e. (COUNT(DISTINCT ?val)/COUNT(?val)).

In some cases the optimizer can prioritize triple patterns that have low cardinality but are unselective. For example, in Wikidata the properties that link Wikidata entities with Wikipedia pages have similar cardinality. See the Halyard Stats for schema:about, schema:inLanguage, and schema:isPartOf:

PREFIX halyard: <http://merck.github.io/Halyard/ns#>
PREFIX schema:  <http://schema.org/>
PREFIX void:    <http://rdfs.org/ns/void#>

SELECT ?property ?cardinality
WHERE {
  GRAPH halyard:statsContext {
    VALUES ?property {
      schema:about
      schema:inLanguage
      schema:isPartOf
    }
    [] void:propertyPartition [
        void:property ?property ;
        void:triples ?cardinality
      ] .
  }
}
property cardinality
schema:about "126270886"^^xsd:long
schema:inLanguage "67986056"^^xsd:long
schema:isPartOf "67986056"^^xsd:long

schema:about has the highest cardinality, but it has vastly better object selectivity than schema:inLanguage or schema:isPartOf, which have only few distinct values. Given that the object of schema:about is known, the query optimizer would produce a better plan if it gave it a priority. While the object selectivity of schema:about is high, since most of its objects are unique (i.e. Wikidata entities), the object selectivity of schema:inLanguage is low, since it has very few unique objects (i.e. languages of Wikipedias).

Adding selectivity to Halyard Stats can mean adding 2 numbers to each partition, e.g., for property partitions it's selectivity with respect to objects and selectivity with respect to subjects. These can be then used by the query optimizer to produce better query plans.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the Halyard Stats component and the query optimizer entry points; the issue does not name specific files or tests. Determine how property-partition cardinalities are computed and consumed, then verify that subject and object selectivity are incorporated into planning and improve the example query plans described in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
databases, performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.