Wikidata:SPARQL query service/WDQS backend update/Graph split IGUANA performance

This page summarizes the analysis from Compare the performance of sparql queries between the full graph and the subgraphs (T355037). The purpose of this analysis was to identify whether there were significant performance increases to be had with a shrunken Wikidata Query Service ("WDQS") Blazegraph database.

Refer to Wikidata:SPARQL query service/WDQS backend update/February 2024 scaling update for more information about the graph split endpoints.

Summary

The "main" graph (non-scholarly article graph) modestly outperformed the "full" graph based on testing with the IGUANA performance tool.

For a sample of bot queries, the "main" graph performed about 5%-6% faster. For a sample of queries from all query sources the "main" graph performed about 3.6% faster.

A couple important notes:

• These were not uncapped load tests, but rather performance tests that simulated four concurrent queries with an evenly distributed delay of up to 100ms between queries, in order to model a busy, but not completely overwhelmed, WDQS node. WDQS enforces rate limiting on requests normally, and so this approach is meant to avoid wholly unrealistic load.
• This analysis was conducted only with queries shown to be capable of succeeding against both graphs from the analysis in Compare the results of sparql queries between the fullgraph and the subgraphs (T355040), with the provision that their result sets after some re-ordering looked the same.

Next steps

A means will need to be identified for performing queries that are valid against the "full" graph, but where the result sets didn't match against the "main" graph well during Compare the results of sparql queries between the fullgraph and the subgraphs (T355040), particularly for scholarly entity-related queries. Comparison of scholarly entity-related queries using the (a) "full" graph versus the (b) federated combination of the "main" and "scholarly" graphs, for the queries shown to have the same result sets, will be useful in understanding the performance tradeoffs and possible query tuning as work continues on the graph split.

The sorts of queries where it was hard to find equivalence in result sets between a query issued against the "full" and the "main" graph tended to be those involving scholarly entities (in which case such queries are likely to require SPARQL federation) or queries involving random sampling or nondeterministic paging (by the query agent or Blazegraph) or artifacts of the "full" and "main" graphs genuinely having a different shape in the underlying database's files. Additionally, in cases where WDQS relied upon a backend MediaWiki API, it was less likely for there to be a matching result set.