In this lesson, you will learn how to standardize your performance testing using the Linked Data Benchmark Council (LDBC) suite to ensure your graph database scales reliably.
The Challenge of Graph Benchmarking
Unlike relational databases, where performance is often measured by simple JOIN throughput, graph database performance is highly sensitive to the depth of traversal and the density of connections. Running a generic query won't tell you how your system handles a "supernode" or a deep recursive path. To solve this, we rely on the LDBC Social Network Benchmark (SNB).
Understanding the LDBC Approach
The LDBC SNB simulates a social media platform, providing a standardized dataset that mimics real-world complexity, including power-law distributions (where a few nodes have millions of connections). It evaluates your system using two specific workloads:
- Interactive Workloads: These measure latency for queries that look like human browsing (e.g., "Find all friends of friends who like a specific topic"). These tests stress the Index-Free Adjacency of your storage engine.
- Business Intelligence (BI) Workloads: These measure throughput for complex analytical queries that touch large portions of the graph, such as community detection or long-path aggregations.
How to Evaluate
When running a benchmark, you aren't just looking for "speed." You are looking at how performance scales as the graph size grows. A key metric is the Scale Factor (SF)—an artificial multiplier that increases the number of users, posts, and likes.
For instance, if your query execution time increases linearly as the Scale Factor increases, your graph partitioning and traversal logic are likely healthy. If you observe exponential growth, your system may be struggling with high-degree nodes or inefficient memory management.
/* Conceptual query for an LDBC Interactive Task */
MATCH (person:Person {id: $personId})-[:KNOWS*1..2]-(friend)
WHERE friend.creationDate > $date
RETURN count(DISTINCT friend) AS result;
By running this against the LDBC-provided data, you can isolate whether your database’s performance bottleneck is in the pattern matching engine, the index lookups, or the memory allocation for large subgraph extractions.
Key Takeaway: Use the LDBC SNB to simulate realistic data distributions, ensuring your graph database maintains consistent performance even as the graph grows in complexity and scale.