This paper introduces an implementation for processing property graph path queries using a subset of SQL/PGQ on Apache Spark. Property graphs, which allow nodes and edges to have multiple labels and properties, are increasingly adopted across diverse domains. SQL/PGQ, an ISO-standard extension to SQL introduced in 2023, enables expressive graph pattern queries in combination with traditional relational operations. However, publicly documented approaches and performance baselines for its distributed execution on open-source platforms are still lacking. To address this, we implement a processor for this subset of SQL/PGQ on Apache Spark, with the goal of establishing a performance baseline for a direct implementation approach. We evaluate its performance by comparing query execution times against other systems. Our experimental results indicate that while the implementation shows notable overhead for queries with small result sets, presumably due to scan and communication costs, it can outperform existing systems for queries that produce large outputs.

错误:搜索内容不能为空,请输入英文关键词
错误:关键词超出字数限制,请精简
高级检索

Parallel and Distributed SQL/PGQ Query Processing for Property Graphs

  • Kosuke Yamasaki,
  • Tadashi Masuda,
  • Toshiyuki Amagasa

摘要

This paper introduces an implementation for processing property graph path queries using a subset of SQL/PGQ on Apache Spark. Property graphs, which allow nodes and edges to have multiple labels and properties, are increasingly adopted across diverse domains. SQL/PGQ, an ISO-standard extension to SQL introduced in 2023, enables expressive graph pattern queries in combination with traditional relational operations. However, publicly documented approaches and performance baselines for its distributed execution on open-source platforms are still lacking. To address this, we implement a processor for this subset of SQL/PGQ on Apache Spark, with the goal of establishing a performance baseline for a direct implementation approach. We evaluate its performance by comparing query execution times against other systems. Our experimental results indicate that while the implementation shows notable overhead for queries with small result sets, presumably due to scan and communication costs, it can outperform existing systems for queries that produce large outputs.