Terrace: Exploiting Graph Skewness for Blazing Fast Streaming Updates

Terrace: A Hierarchical Graph Container for Skewed Dynamic Graphs

2021-06-09
Prashant Pandey, Brian Wheatman, Helen Xu, Aydin Buluç
Summary
Problem
Method
Results
Takeaways
Abstract

Terrace is a high-performance hierarchical graph container designed for streaming graphs with skewed degree distributions. It achieves state-of-the-art performance by dynamically partitioning vertex neighbors into three distinct data structures based on vertex degree: in-place arrays, a shared Packed Memory Array (PMA), and per-vertex B-trees.

TL;DR

Terrace is a new dynamic graph system that recognizes a simple truth: not all vertices are created equal. By using a three-level hierarchical storage engine—in-place slots for small vertices, a shared Packed Memory Array for medium ones, and B-trees for "superstars"—it achieves the update speed of streaming systems while matching the query performance of static, optimized frameworks like Ligra.

Problem & Motivation: The "One-Size-Fits-All" Tax

Most real-world graphs (social networks, web graphs) are highly skewed. As shown in the paper's characterization, over 60% of vertices in datasets like LiveJournal have fewer than 10 neighbors, while a few "hub" vertices might have millions.

The Problem:

  • Static Systems (like Ligra) use CSR (Compressed Sparse Row). It's incredibly fast to read but requires a full graph rebuild for updates—useless for streaming.
  • Dynamic Systems (like Aspen) use trees for everything. While great for updates, traversing a tree for a vertex with only 3 neighbors is "cache-locality suicide." You pay for pointer indirection and non-sequential memory access that you don't actually need.

Terrace’s Insight: Use different data structures for different degree regimes. Save the heavy-duty trees for the hubs, and keep the "small fry" in-place to maximize cache hits.

Methodology: The Hierarchical Triple-Threat

Terrace abandons the uniform approach in favor of a degree-dependent hierarchy:

1. In-Place Level (Degree )

Instead of a pointer to a neighbor list, the first few neighbors (up to ) are stored directly inside the vertex structure.

  • Why it works: When a graph traversal visits a low-degree vertex, the neighbors are already in the cache line loaded for the vertex metadata. Zero extra cache misses.

2. Array-Like Level (PMA) (Medium Degree)

For vertices that outgrow the in-place slots but aren't yet "hubs," Terrace uses a Packed Memory Array (PMA).

  • Why it works: PMAs maintain sorted order with gaps, allowing for updates but offering the scan speed of a standard array. By sharing one PMA among many vertices, Terrace keeps medium-degree neighbors contiguous.

3. Tree-Like Level (B-tree) (High Degree)

For high-degree vertices, Terrace assigns a private B-tree.

  • Why it works: At this scale, the cost of one pointer indirection is negligible compared to the cost of scanning thousands of edges. B-trees provide the best balance of search, update, and block-based scan performance.

Model Architecture The Figure above illustrates the three-level design: (left) metadata and in-place slots, (middle) the shared PMA for bulk storage, and (right) the dedicated B-trees.

Experiments: Performance Without Compromise

The authors compared Terrace against Aspen (streaming) and Ligra (static).

Update Throughput

Terrace shines in small-to-medium batch sizes (up to 1M edges), which is the "sweet spot" for most real-world applications like Twitter or Facebook transaction streams. Batch Insert Throughput

Query Latency

In algorithms like BFS and PageRank, Terrace significantly outperforms Aspen because it avoids the "pointer-chasing" tax. Remarkably, it even beats the static Ligra in several cases because the in-place optimization reduces the total number of cache misses.

KernelLigra (Static)Aspen (Dynamic)Terrace (Dynamic)
BFS Cache Misses3.5M6.3M1.1M
PR Cache Misses174M197M128M
Table: Terrace dramatically slashes cache misses compared to both static and dynamic baselines.

Critical Analysis & Conclusion

Takeaway

Terrace proves that we don't have to choose between "fast updates" and "fast queries." By embracing the physical reality of hardware (cache lines) and the mathematical reality of graphs (skewness), we can build systems that adapt.

Limitations

  • Memory Overhead: Terrace uses more memory than Aspen (up to 2x). This is primarily because the PMA and B-trees maintain "empty space" to ensure fast future insertions.
  • Deletion Complexity: While insertions are highly optimized, batch deletions in Terrace are currently slower than Aspen, suggesting a need for better "re-balancing" logic between the levels.

Future Outlook

The move toward Hierarchical Graph Containers is likely the future of graph databases. As GNNs and real-time fraud detection become more prevalent, the ability to ingest data while maintaining high-speed traversal will be the primary bottleneck. Terrace provides the blueprint for solving it.

Find Similar Papers

Try Our Examples

  • Find recent papers that utilize degree-aware partitioning or hybrid data structures for dynamic graph processing beyond Terrace and Aspen.
  • Which paper first introduced the Packed Memory Array (PMA) in the context of graph representations, and how does Terrace's parallel implementation differ?
  • Explore research that applies hierarchical graph storage techniques to Graph Neural Network (GNN) training on streaming or evolving datasets.
Contents
Terrace: Exploiting Graph Skewness for Blazing Fast Streaming Updates
1. TL;DR
2. Problem & Motivation: The "One-Size-Fits-All" Tax
3. Methodology: The Hierarchical Triple-Threat
3.1. 1. In-Place Level (Degree $\le S$)
3.2. 2. Array-Like Level (PMA) (Medium Degree)
3.3. 3. Tree-Like Level (B-tree) (High Degree)
4. Experiments: Performance Without Compromise
4.1. Update Throughput
4.2. Query Latency
5. Critical Analysis & Conclusion
5.1. Takeaway
5.2. Limitations
5.3. Future Outlook