Incremental View Maintenance for Property Graph Queries

Graph processing challenges are common in modern database systems, with the property graph data model gaining widespread adoption [29]. Due to the novelty of the eld, graph databases and frameworks typically provide their own query language, such as Cypher for Neo4j [27], Gremlin for TinkerPop [28] and GraphScript for SAP HANA [24]. These languages often lack a formal background for their data model and semantics [1]. To address this, the openCypher initiative [21] aims to standardise a subset of the Cypher language, for which it currently provides grammar speci cation and a set of acceptance tests to allow vendors to implement their openCypher compatible engine. Incremental view maintenance has been used for decades in relational database systems [4]. In the graph domain, numerous use cases rely on complex queries and require low latency, including nancial fraud detection, source code analysis [32] and checking integrity (or well-formedness) constraints in databases [30]. While these could bene t from incremental evaluation, currently no property graph system provides incremental views. Our research investigates the incremental view maintenance for openCypher queries. A key challenge is that the property graph data model includes lists and maps, and queries can return arbitrarily nested data structures. We propose three desirable properties for an incremental property graph query engine: (IVM) incremental view maintenance, (FGN) ne granularity update operations on nested data structures, (ORD) ordering. Previous research showed that IVM and FGN is possible [19]. However, as stated in [8], "incremental view maintenance [IVM] strategies for data models that preserve order [ORD] remain an open problem to date". While removing support for ordering might seem a plausible workaround, it would pose serious limitations: (1) queries that require top-k results are common [17] and (2) even more importantly, Cypher handles paths as an alternating list of vertices and edges, which must be kept ordered. Therefore, we investigate the following research question: Which practical fragment of the openCypher language is incrementally maintainable?