diff --git a/docs/images/gopt/design_of_gopt.png b/docs/images/gopt/design_of_gopt.png new file mode 100644 index 000000000000..baa608cbb9fc Binary files /dev/null and b/docs/images/gopt/design_of_gopt.png differ diff --git a/docs/images/gopt/movie_data.png b/docs/images/gopt/movie_data.png new file mode 100644 index 000000000000..b00f21bbb029 Binary files /dev/null and b/docs/images/gopt/movie_data.png differ diff --git a/docs/images/gopt/movie_schema.png b/docs/images/gopt/movie_schema.png new file mode 100644 index 000000000000..f54f02d8c368 Binary files /dev/null and b/docs/images/gopt/movie_schema.png differ diff --git a/docs/images/gopt/square_pattern_profile.png b/docs/images/gopt/square_pattern_profile.png new file mode 100644 index 000000000000..7c00c813cf0b Binary files /dev/null and b/docs/images/gopt/square_pattern_profile.png differ diff --git a/docs/images/gopt/square_pattern_with_filter_profile.png b/docs/images/gopt/square_pattern_with_filter_profile.png new file mode 100644 index 000000000000..13e92f7d94d0 Binary files /dev/null and b/docs/images/gopt/square_pattern_with_filter_profile.png differ diff --git a/docs/images/gopt/st_path_profile.png b/docs/images/gopt/st_path_profile.png new file mode 100644 index 000000000000..5571a7f13ba5 Binary files /dev/null and b/docs/images/gopt/st_path_profile.png differ diff --git a/docs/images/gopt/system_overview.png b/docs/images/gopt/system_overview.png new file mode 100644 index 000000000000..110d4c0c385b Binary files /dev/null and b/docs/images/gopt/system_overview.png differ diff --git a/docs/images/gopt/triangle_pattern_profile.png b/docs/images/gopt/triangle_pattern_profile.png new file mode 100644 index 000000000000..3724d67e3866 Binary files /dev/null and b/docs/images/gopt/triangle_pattern_profile.png differ diff --git a/docs/images/gopt/type_error_profile.png b/docs/images/gopt/type_error_profile.png new file mode 100644 index 000000000000..5fcffac0ab37 Binary files /dev/null and b/docs/images/gopt/type_error_profile.png differ diff --git a/docs/index.rst b/docs/index.rst index 0ffd847465d0..5d880d62f575 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -73,7 +73,7 @@ and the vineyard store that offers efficient in-memory data transfers. interactive_engine/deployment interactive_engine/tinkerpop_eco interactive_engine/neo4j_eco - interactive_engine/optimizer + interactive_engine/gopt .. interactive_engine/guide_and_examples interactive_engine/design_of_gie .. interactive_engine/supported_gremlin_steps diff --git a/docs/interactive_engine/gopt.md b/docs/interactive_engine/gopt.md new file mode 100644 index 000000000000..391b76559f18 --- /dev/null +++ b/docs/interactive_engine/gopt.md @@ -0,0 +1,352 @@ +# GOpt: A Graph-Native Query Optimization Framework +## Introducing GOpt +GOpt is a graph-native query optimizer designed to accelerate query execution. It excels in handling hybrid scenarios that combine complex graph pattern matching with relational operations on large graphs. GOpt is not aware of the underlying storage data and focuses solely on computation on top of the data, which makes it easy and fast to be integrated into other graph or relational databases. + +### Core Features + +1. **Property Graph Modeling**: Automatically infers and completes user-provided ambiguous queries for more accurate optimization. +2. **Language Support**: Supports standard [Gremlin](https://tinkerpop.apache.org/gremlin.html) and [Cypher](https://neo4j.com/docs/cypher-manual/current/introduction/) languages, with upcoming [GQL](https://www.gqlstandards.org/) support. +3. **Graph-Native Algorithms**: Implements novel and efficient algorithms for complex graph pattern matching queries. +4. **Lightweight, Serverless Integration**: Seamlessly integrates with databases of various storage formats. + +:::{figure-md} + +system_overview + +GOpt System Overview +::: + +### Why GOpt + +1. **High Performance** + + GOpt is designed and implemented based on years of academic research, with key techniques published in prestigious systems conferences. Our experiments, as documented in our [papers](https://arxiv.org/abs/2401.17786), demonstrate that GOpt outperforms most graph and relational databases in both standard ([LDBC](https://ldbcouncil.org/)) and real-world (Alibaba) graph workloads. + +2. **User-Friendly Interface** + + GOpt offers different layers of SDK tailored to various user requirements. It provides Cypher and Gremlin language support to lower the barrier of entry. User-provided Cypher or Gremlin queries can be more flexible and ambiguous, with GOpt automatically validating and completing the query information based on property graph modeling. Additionally, it provides lower-level APIs for developers who require deeper integration. + +3. **Seamless Integration** + + GOpt is lightweight and serverless, facilitating seamless integration into other databases through a small-sized JAR file deployment. Built on the Calcite framework, GOpt leverages Calcite's extensive range of adapters, simplifying the integration with various data formats. This advantage allows GOpt to seamlessly integrate with mainstream relational databases that has been powered by Calcite. Additionally, GOpt is equipped with graph-native algorithms, enhancing its compatibility with graph-native database APIs. In our [Getting Started](#getting-started) section, we provide a demonstration of GOpt's easy integration into Neo4j with minimal codes. + +## Getting Started + +### Quick Start +GOpt is embeddable and serverless, available as a standalone package occupying just a few tens of MB in a JAR file. It can be quickly integrated into other systems as project dependency via Apache Maven. We have already integrated GOpt into the Neo4j system. Here, you can quickly experience the optimization effects that GOpt brings to Neo4j. + +#### Deployment + +##### Local Setup +We have prepared a `gopt-on-neo4j.tar.gz` package. You can quickly obtain it through the following link: +[Download GOpt for Neo4j](https://graphscope.oss-cn-beijing.aliyuncs.com/gopt_data/gopt-on-neo4j.tar.gz) + +After unzipping the package, you will get the following artifacts: +```bash +├── bin +├── conf +├── data +├── import +│ └── movie +├── lib +│ └── gopt-all-0.0.1-SNAPSHOT.jar +├── plugins +└── queries + ├── CBO + ├── LSQB + └── LDBC +``` +Based on the original Neo4j artifacts, we made the following modifications: + +1. Added `movie` CSV data to the `import/movie` directory. After successfully importing the data, the corresponding database files will be generated in the `data` directory. +2. Added the `gopt-0.0.1-SNAPSHOT.jar` file to the `lib` directory, making GOpt a project dependency of Neo4j. +3. Added query sets for benchmark tests. + +You can now try running Neo4j with GOpt on your local machine. Note that the Neo4j version we use is 4.4.9. Ensure your local machine has all the necessary environments for [Neo4j-4.4.9](https://github.com/neo4j/neo4j/tree/4.4). If you do not have a complete development environment, you may prefer to use the [Docker setup](#docker-setup). + +##### Docker Setup +If you do not have a complete development environment, we have also prepared a corresponding Docker environment. The Docker image contains all the contents of `gopt-on-neo4j.tar.gz` as well as all the necessary environment dependencies. You can start it with a single command: +```bash +docker run -it registry.cn-hongkong.aliyuncs.com/graphscope/gopt-on-neo4j:latest bash +``` + +#### Importing Data +Use the Neo4j importing tools to load your data into the Neo4j database. Here we use `movie` dataset as an example, which has the following property graph model: + +:::{figure-md} + +movie_schema + +Movie Data Model +::: + +:::{figure-md} + +movie_data + +Nodes and Relationships in the Movie Dataset +::: + +Follow the instructions of [neo4j-admin](https://neo4j.com/docs/operations-manual/4.4/tools/neo4j-admin/) to load the movie dataset, the original CSV files have been included in the `gopt-on-neo4j` artifacts under the directory `import/movie`. +``` +cd gopt-on-neo4j + +bin/neo4j-admin import \ + --database movie \ + --id-type=INTEGER \ + --ignore-empty-strings=true \ + --bad-tolerance=0 \ + --nodes=Person=import/movie/Person.csv \ + --nodes=Movie=import/movie/Movie.csv \ + --relationships=FOLLOWS=import/movie/Person_FOLLOWS_Person.csv \ + --relationships=ACTED_IN=import/movie/Person_ACTED_IN_Movie.csv \ + --delimiter '|' +``` +#### Configuration +We integrate GOpt configuration into the Neo4j standard config file `conf/neo4j.conf` as follows: + +- **graph.planner.rules**: Registers graph relational rules into the GOpt optimizer framework. +- **graph.planner.join.min.pattern.size**: Specifies the minimum pattern size that activates the `JoinDecompositionRule`. It is noted that `Extend` can yield better execution efficiency than `Join` for smaller patterns. +- **graph.planner.intersect.cost.factor**: For performance tuning, a higher value biases the optimizer towards more join-based plans, while a lower value favors extend-based plans. + +Besides the GOpt configuration, we set the default database to `movie`. +``` +# GOpt Configuration +graph.planner.rules=FilterIntoJoinRule,FilterMatchRule,ExtendIntersectRule,JoinDecompositionRule,ExpandGetVFusionRule +graph.planner.join.min.pattern.size:3 +graph.planner.intersect.cost.factor:1 + +# The name of the default database +dbms.default_database=movie +``` + +#### Starting Neo4j Service +```bash +./bin/neo4j start + +# wait unitl neo4j service started +... + +./bin/cypher-shell + +# check graph model +call apoc.meta.graph(); + +# check data +Match (a) Return count(a); +Match (a)-[b]->(c) Return count(b); +``` + +#### Analyzing Queries +To experience the optimization effects of GOpt, you can run various types of queries and observe the detailed profiling results. GOpt integrates Neo4j's Profile tool to display estimated counts for each operation. By comparing these estimates with the actual row counts, you can verify the accuracy of GOpt's cardinality estimation. + +##### Ambiguous Pattern +Execute queries where type constraints are not explicitly defined. +```bash +Profile Match (a)-[]->(b), (b)-[]->(c), (c)-[]->(a) Return a, b, c; +``` +From the execution explanation provided by Neo4j profile tools, it is evident that nodes a, b, and c, as well as the types of relationships between them, are precisely inferred. This allows the GOpt optimizer to operate effectively without being hindered by the lack of type details in queries, addressing Neo4j's limitation where it defaults to rule-based optimization (RBO) in the absence of such information, which prioritizes nodes with defined types. + +:::{figure-md} + +triangle_pattern_profile + +Ambiguous Pattern Profiling Results +::: + +An important point to note is that if the data model does not contain the pattern specified in the query, GOpt can provide timely errors during the compiling phase through static analysis prior to actual data execution. For instance, If GOpt's static analysis determines that there are no outgoing edges associated with `Movie` in the data model, it will promptly raise an error. +```bash +Profile Match (a:Movie)-[]->(b) Return a, b; +``` + +:::{figure-md} + +type_error_profile + +Pattern with Type Error Profiling Results +::: + +##### Graph Pattern Matching +Find all square patterns. +```bash +Profile Match (a)-[]->(b), (a)-[]->(c), (d)-[]->(b), (d)-[]->(c) +Where a<>d AND b<>c +Return a, b, c, d; +``` +Graph-native algorithms (i.e. [worst-case-optimal join](https://dl.acm.org/doi/10.1145/3180143) algorithm) are adopted to optimize the complex graph pattern matching workloads. The WCO implementation is not natively supported in the Neo4j execution layer. However, we can still use GOpt to optimize the order of `Expand` operations in Neo4j. For cyclic patterns, we transform the logical operator generated by the WCO algorithm into Neo4j's specific physical operator, `ExpandInto`. + +:::{figure-md} + +square_pattern_profile + +Square Pattern Profiling Results +::: + +##### Hybrid Graph Relational +Based on the provided filtering conditions, the optimizer seamlessly integrates graph-native algorithm with the traditional relational rule `FilterPushDown`, which results in a distinct execution order from that of query-2. +```bash +Profile Match (a)-[]->(b), (a)-[]->(c), (d)-[]->(b), (d)-[]->(c) +Where d.name = 'Kean' AND a<>d AND b<>c +Return a, b, c, d; +``` + +:::{figure-md} + +square_pattern_with_filter_profile + +Square Pattern with Filtering Profiling Results +::: + +##### ST Path +Find the count of all simple paths between two given vertices. GOpt provides specific optimizations for ST-Path queries. For long paths between a given start and endpoint, it selects an appropriate split point based on cardinality estimation to reduce data expansion in a single direction. This is a feature not available in the native Neo4j planner. +```bash +Profile Match (a)-[:ACTED_IN*5..6]-(b) +Where a.name = 'Kean' AND b.name = 'Top Gun' +Return count(a); +``` + +:::{figure-md} + +st_path_profile + +ST-Path Pattern Profiling Results +::: + +### Installation +We offer two versions of the GOpt JAR package, each approximately 35MB in size: + +- **gopt-core**: Includes the core functionality of GOpt and uses the GraphBuilderSDK to build GOpt inputs. +- **gopt-all**: Builds on top of gopt-core by providing additional Cypher SDK and Gremlin SDK, allowing users to directly write Cypher or Gremlin queries to build GOpt inputs. + +To try GOpt in your own project, download the latest version of the [gopt-core](https://graphscope.oss-cn-beijing.aliyuncs.com/gopt_data/gopt-core-0.0.1-SNAPSHOT.jar) or [gopt-all](https://graphscope.oss-cn-beijing.aliyuncs.com/gopt_data/gopt-all-0.0.1-SNAPSHOT.jar) and place it in the `src/main/resources` directory. +```bash + + gopt + com.alibaba.graphscope + 0.0.1-SNAPSHOT + system + ${project.basedir}/src/main/resources/gopt-core-0.0.1-SNAPSHOT.jar + +``` +```bash + + gopt + com.alibaba.graphscope + 0.0.1-SNAPSHOT + system + ${project.basedir}/src/main/resources/gopt-all-0.0.1-SNAPSHOT.jar + +``` + +## Tutorial + +In the [Getting Started](#getting-started) section, we explored some basic features of GOpt. In this section, we will guide you through advanced features of GOpt and demonstrate how to leverage these capabilities to optimize your system, including: +- **GOpt Benchmark Tools**: This guide provides detailed instructions on utilizing the benchmark tool to evaluate GOpt's performance on more complex queries with larger datasets. +- **Integration of GOpt into Other Systems**: Using Neo4j as a case study, we provide comprehensive details on integrating GOpt into other systems at different levels. + +### Benchmark Tools +We provide a benchmark tool for running complex pattern queries on larger datasets. Our benchmark tool includes three components: + +- **Dataset**: We have pre-prepared the LDBC data with sf=1 in the artifacts `gopt-on-neo4j`, under `data` directory. +- **Queries**: We have prepared three sets of query collections in the `queries` directory, including: + 1. **CBO**: Designed for commonly used graph patterns, including triangles, squares, paths, and 4-cliques. + 2. **LSQB**: A subset of standard LSQB queries. + 3. **LDBC**: Simplified versions of standard LDBC queries. +- **Scripts**: The `bin/bench.sh` script is used to run the benchmark. + +You can now experience our one-click benchmarking feature. + +#### Steps + +1. First, stop the running service + ```bash + bin/neo4j stop + ``` + +2. Reconfigure the database to `ldbc1`, and set the performance tuning configuration for GOpt + ``` + dbms.default_database=ldbc1 + graph.planner.intersect.cost.factor:3 + ``` + +3. Restart the Neo4j service, and confirm that the data is ready + ```bash + bin/neo4j start + # wait unitl neo4j service started + ... + + ./bin/cypher-shell + + # check graph model + call apoc.meta.graph(); + + # check data + Match (a) Return count(a); + ``` + +4. Experience the various features of `bench.sh` by passing different parameters. + 1. Run the CBO query set in profile mode to print detailed profiling results. Alternatively, you can use explain mode, which returns the optimized plan without executing it. + ```bash + ./bin/bench.sh ./queries/CBO --profile + ./bin/bench.sh ./queries/CBO --explain + ``` + + 2. You can choose other query sets or run all query sets under `queries` + ```bash + ./bin/bench.sh ./queries/LSQB --profile + ./bin/bench.sh ./queries/LDBC --profile + ./bin/bench.sh ./queries --profile + ``` + + 3. By default, we skip large queries that are time-consuming. You can use `--all` to run all queries, but this will take more time due to Neo4j's low execution efficiency on single node resources. + ```bash + ./bin/bench.sh ./queries --profile --all + ``` + + 4. Optionally, you can switch to the Neo4j native planner by setting `--neo4j`. This allows you to analyze the differences from GOpt. Be sure to clear the query caches before switching between planners. + ```bash + # clean query cache + ./bin/cypher-shell 'call db.clearQueryCaches();' + + ./bin/bench.sh ./queries --profile --neo4j --all + ``` + +### Integration of GOpt +Detailed integration instructions for GOpt will be provided in the following sections. Stay tuned for more information. + +## Design of GOpt +### Motivation +In large-scale graph querying scenarios, one core technique that can significantly influence performance is the optimizer. As graph data and its applications continue to grow rapidly, numerous graph processing systems equipped with native optimizers have been developed. However, these optimization methods tend to excessively focus on either graph-specific or relational-specific approaches. This narrow focus fails to holistically address queries involving both graph and relational data, leading to suboptimal performance. +To address this issue, GOpt is designed as follows: + +1. **Unified Graph Relational Design**: Develop a unified structure for Graph Relational that can express Gremlin or Cypher queries, serving as the initial structure for optimization. +2. **Unified Optimization Framework**: Optimize the graph relational structure within a unified relational optimization framework. We extended the interfaces of traditional relational frameworks to implement advanced graph optimizations, including high-order statistics and worst-case optimal join algorithms. +3. **Graph-Specific Optimization**: We also employed specific optimizations for graph pattern matching based on the characteristics of graphs. For instance, we extended type inference for graph patterns based on property graph modeling, leveraged graph isomorphism for pruning in traditional optimization frameworks, and implemented a specialized graph decomposition algorithm to reduce the search space during the optimization process. + +:::{figure-md} + +design_of_gopt + +Design of GOpt +::: + +### Detailed Introduction +A comprehensive introduction to GOpt will be provided in subsequent sections. Please stay tuned for detailed updates and information. diff --git a/docs/interactive_engine/optimizer.md b/docs/interactive_engine/optimizer.md deleted file mode 100644 index 6a3e45482a2b..000000000000 --- a/docs/interactive_engine/optimizer.md +++ /dev/null @@ -1,140 +0,0 @@ -# A Generic Graph Optimizer for GIE - -We have developed a versatile graph optimizer for the Graph Interactive Engine (GIE), capable of optimizing the execution for multiple query languages in GraphScope, including [Gremlin](./tinkerpop_eco) and [Cypher](./neo4j_eco). This optimizer is built upon the [Apache Calcite](https://calcite.apache.org/) framework, traditionally focused on relational databases, but now extended to accommodate graph databases by incorporating graph-specific operations and rules. The optimizer consists of two main components: the Rule-based Optimizer (RBO) and the Cost-based Optimizer (CBO). Like their relational counterparts, both RBO and CBO utilize pre-registered rules for transformation and path optimization, either through heuristic methods or cost estimation. However, our optimizer differs from standard relational optimizers in two key aspects: - -1. **Graph-specific Rules**: Our optimizer integrates rules for specific graph operators within Graph and Relational databases, allowing for true optimization where Graph and Relational structures coexist. Relational operators directly benefit from the reuse of existing SQL rules. - -2. **High-Order Statistics in CBO**: Our Cost-Based Optimizer (CBO) utilizes sophisticated statistical models grounded in graph structures, providing more accurate cardinality estimates compared to conventional optimizers. The foundational work for our CBO primarily stems from the research presented in [GlogS](https://www.usenix.org/conference/atc23/presentation/lai), which was published at ATC 2023. This research has been instrumental in enhancing the efficacy of graph pattern matching, setting a new standard for optimization in graph databases. - -## Rule-based Optimizer (RBO) - -| Rule Name | Description | -|------------------------|--------------------------------------------------------------| -| FilterMatchRule | Pushes filter conditions to graph operators in `Match`. | -| DegreeFusionRule | Uses pre-calculated degrees of vertices from graph storage. | -| NotMatchToAntiJoinRule | Converts `Where Not` queries into anti-joins. | -| FieldTrimRule | Removes unnecessary aliases or properties. | - -This table offers a concise overview of the existing rules for RBO. Each rule is designed to optimize graph query performance by transforming the way queries are processed and executed. Examples of how these rules conceptually affect the execution of queries are detailed as follows. Note that we use Cypher as the query language for demonstration purposes, but the rules apply to Gremlin as well. - -### FilterMatchRule -This rule pushes filter conditions down to individual graph operators within a `Match` clause. For example: -```bash -Match (p1:PERSON)-[:KNOWS]->(p2:PERSON) -Where p1.id = $id1 and p2.id = $id2 -Return p1, p2; -``` -becomes: -```bash -Match (p1:PERSON {id: $id1})-[:KNOWS]->(p2:PERSON {id: $id2}) -Return p1, p2; -``` -following the push-down, splitting the `Where` clause to filter directly at the vertices p1 and p2. - -### DegreeFusionRule -The DegreeFusionRule capitalizes on the fact that most graph storage systems already maintain the count of neighbors (i.e., the degree) for each vertex. For example: -```bash -Match (p1:PERSON {id: $id1})-[]->(p2) -Return p1, COUNT(p2); -``` -With this rule applied, instead of individually counting each neighbor of `p1`, we can directly obtain `p1`'s degree, streamlining the process considerably. This optimization effectively utilizes preexisting graph data structures to expedite query execution. - -### NotMatchToAntiJoinRule -This rule converts queries containing `Where Not` clauses into the equivalent anti-join structures, where the anti-join -is a relational operator that returns all rows from the left table that fail to match with the right table. -Consider the following query: -```bash -Match (p1:PERSON)-[:KNOWS]->(:PERSON)-[:KNOWS]->(p2:PERSON) -Where Not (p1)-[:KNOWS]->(p2) -Return p1, p2; -``` -Under this rule, the query is transformed to: -```bash -Match (p1:PERSON)-[:KNOWS]->(:PERSON)-[:KNOWS]->(p2:PERSON) - -Match (p1)-[:KNOWS]->(p2) -Return p1, p2; -``` -Here, `` serves as a conceptual operator, used here to effectively illustrate how the original query's intent is preserved while enhancing its execution efficiency. - -### FieldTrimRule -Removes unnecessary aliases or properties, reducing data processing. Consider: -```bash -Match (p1:PERSON)-[k1:KNOWS]->(p2:PERSON)-[k2:KNOWS]->(p3:PERSON) -Return p1.name; -``` -Here, only `p1.name` is required in the output, making aliases like k1, k2, and properties of p2, p3 redundant. -This rule optimizes to retain only necessary data, significantly reducing the volume of the intermediate results. - -## Cost-based Optimizer (CBO) -TODO - -## Graph Type Inference -Traditional SQL only provides checks and inference for basic data types, such as int, double, string, boolean, etc. However, graph databases encompass more complex types. Beyond basic data types, they introduce special vertex and edge types. Vertex types constrain the range of entity types within the graph, while edge types constrain relationships between entities. While the introduction of vertex and edge types in graph databases provides a more flexible data model, it simultaneously adds complexity to the data, necessitating type checks and inference for graph data. - -We address this complexity through Graph Type Inference, offering functionality for type checks and inference for graph data. This feature examines whether vertex and edge types in graph data adhere to user-defined schemas and can infer vertex and edge types, laying the groundwork for subsequent optimizations in graph queries. - -Taking the example of a modern graph schema, which includes the following vertex and edge types: -``` -# Vertex types -person (name, age) -software (name, lang) - -# Edge types -knows (weight) -created (weight) -``` -Graph Type Inference provides the following capabilities: -- Checking if vertex and edge types in the graph conform to user-defined schemas: - - Reporting errors for nonexistent vertex or edge types: - ```bash - # 'per' is a nonexistent vertex type - Match (a:per) Return a; - ``` - ```bash - # 'kno' is a nonexistent edge type - Match (a:person)-[b:kno]->(c) Return a, b, c; - ``` - - Reporting errors for nonexistent properties or mismatched property types in vertices or edges: - ```bash - # The 'lang' property does not exist in vertices of type 'person' - Match (a:person {lang: 'java'}) Return a; - ``` - ```bash - # The 'name' property in vertices of type 'person' is of type string, cannot perform addition - Match (a:person) Return a.name + 1; - ``` - - Reporting errors for invalid paths composed of vertices and edges: - ```bash - # There is no edge of type 'created' between vertices of type 'person' - Match (a:person)-[:created]->(b:person) - ``` - ```bash - # Vertices of type 'software' have no outgoing edges - Match (a:software)-[b]->(c); - ``` -- Inferring vertex and edge types in the graph: - - Inferring vertex types given edge types: - ```bash - # (?)-[knows]->(?) => (person)-[knows]->(person) - Match (a)-[:knows]->(b) Return labels(a), labels(b); - ``` - ```bash - # (?)-[knows*1..4]->(?) => (person)-[knows*1..2]->(person) - Match (a)-[:knows*1..4]->(b) Return labels(a), labels(b); - ``` - - Inferring edge types given vertex types: - ```bash - # (person)-[?]->(person) => (person)-[knows]->(person) - Match (a:person)-[b]->(c:person) Return type(b); - ``` - - Inferring all vertex and edge types given a path: - ```bash - # (?)-[?]->(?)->[?]->(software) => (person)-[knows]->(person)->[created]->(software) - Match (a)-[b]->(c)-[d]->(:software) Return labels(a), type(b), labels(c), type(d); - ``` - - Inferring across multiple sentences: - ```bash - # (?)-[]->(?), (?)-[knows]-(?) => (person)-[knows]-(person), (person)-[knows]-(person) - Match (a)-[b]-(c), (a)-[:KNOWS]-(c) Return labels(a), type(b), labels(c); - ```