GraphConnect EU 2017 - Performance Improvements in Neo4j 3.2
2 likes199 views
The document outlines performance improvements in Neo4j 3.2, focusing on enhancements in native graph, Cypher parser, and runtime performance. Key upgrades include significantly faster native label index writes, improved multi-property query capabilities through composite indexes, and a complete rewrite of the Neo4j browser for better speed. Additionally, the compiled Cypher runtime supports more operators and offers performance boosts ranging from 2x to 20x faster for various queries.
![Reachability Queries - Pruning Var Expand
MATCH (kevin {name:'Kevin Bacon'})-‐[*1..5]-‐(actor)
RETURN DISTINCT actor](https://image.slidesharecdn.com/gceu2017performanceimprovements-170717141223/85/GraphConnect-EU-2017-Performance-Improvements-in-Neo4j-3-2-9-320.jpg)
GraphConnect EU 2017 - Performance Improvements in Neo4j 3.2
- 1. Craig Taverner Cypher Team Lead Performance Improvements in Neo4j 3.2
- 3. Native Graph Performance Improvements • Native Label index: Writes now 30-300% faster • Composite indexes: Faster multi-property queries • Reachability Queries: Can improve by orders of magnitude • Compiled Cypher runtime: Speeds queries up to 300% • Neo4j Browser: Ground-up rewrite yields snappier performance
- 4. Cypher Parser Performance Improvements in Neo4j 3.2 • Native Label Index • Composite Indexes • Compiled Runtime • Reachability (Pruning Var Expand) • Solving OR Using Indexes Cypher Planner Cypher Runtime Neo4j Kernel Storage CompositeIndexes Compiled Native Label Index PruningVXOr
- 5. Native Label Index • New GBPTree Index • Designed for concurrent read and write load • Performance • Similar for reads • Faster for writes
- 6. Composite Indexes Full-stack generalisation of schema indexes to multiple properties • Cypher: CREATE INDEX ON :Person(firstname,lastname) MATCH (n:Person) WHERE n.firstname = 'Joe' AND n.lastname = 'Soap' RETURN n; • Core API: gds.schema().indexFor(Label.label("Person")) .on("firstname") .on("lastname") .create();
- 7. Composite Indexes Cypher queries will use the composite index if the following conditions exist: • Predicates must exist for all properties in the index and be equality predicates for the index to be used. • Predicates for existence, range, starts-with, ends-with and contains will not be able to use the index (yet). CREATE INDEX ON :Person(firstname, lastname); // Direct composite index search on multiple property equality MATCH (n:Person) WHERE n.firstname = 'Joe' AND n.lastname = 'Soap' RETURN n; // No use of composite index (yet) MATCH (n:Person) WHERE n.firstname = 'Joe' AND exists(n.lastname) RETURN n; MATCH (n:Person) WHERE n.firstname = 'Joe' AND n.lastname STARTS WITH 'Soap' RETURN n; MATCH (n:Person) WHERE n.firstname = 'Joe' RETURN n;
- 9. Reachability Queries - Pruning Var Expand MATCH (kevin {name:'Kevin Bacon'})-‐[*1..5]-‐(actor) RETURN DISTINCT actor
- 10. Compiled Runtime • Coverage • 50% of Cypher Operators supported • Cypher Benchmarks Suite 15% supported • LDBC suite 18% supported • Does this mean many simple and few complex? • Performance • Operators 2x to 20x faster • Queries … well it depends… let’s say 2x for supported queries
- 11. Compiled Runtime - Operators
- 12. Compiled Runtime - Operators
- 13. Compiled Runtime - LDBC Benchmarks
- 14. Compiled Runtime
- 15. Solving OR using Indexes • Consider AND MATCH (n:X) WHERE n.firstName = $first AND n.lastName = $last RETURN n • Solved with Index and Filter - FAST • But what happens with OR MATCH (n:X) WHERE n.firstName = $first OR n.lastName = $last RETURN n • 3.1: Solved with LabelScan and Filter - SLOW • 3.2: Solved with two IndexSeeks - FAST
- 16. Solving OR using indexes
- 17. Resources • Compiled Runtime Coverage Performance Improvements in Neo4j 3.2