Keyword Search on External Memory Data Graphs

Bhavana Dalvi* Meghana Kshirsagar# S. Sudarshan Indian Institute of Technology, Bombay

Keyword Search on Graph Data

Motivation: querying of data from (possibly) multiple data sources

E.g. Organizational, government, scientific, medical Often no schema or partially defined schema Lowest common denominator model, across relational, HTML, XML, RDF, Much recent work on extracting and integrating data into a graph model

Graph data model

Keyword search is a natural way to query such data graphs, esp. in the absence of schema

This is the focus of this paper

Keyword Search on Graph-Structured Data

E.g. query: soumen byron Key differences from IR/Web Search:

Normalization (implicit/explicit) splits related data across multiple nodes To answer a keyword query we need to find a (closely) connected set of entities that together match all given keywords
3

Query/Answer Models on Graph Data

Query : set of keywords Answer: rooted directed tree connecting keyword nodes (e.g. BANKS) Answer relevance based on

paper Focused Crawling

writes

writes

node prestige 1/(tree edge weight)

author Soumen C.

author Byron Dom

Several closely related ranking models

query: soumen byron

Keyword Search on Graphs

Backward expanding search Bidirectional search DPBF, BLINKS, Spark,

All above algorithms assume graph fits in memory

External Memory Graph Search

Problem: what if graph size > memory? Motivation: Web crawl graphs, social networks, Wikipedia, data generated by IE from Web Algorithm Alternatives: Alternative 1: Virtual Memory ve: thrashing (experimental results later) Alternative 2: SQL ve: For relational data only ve: not good for top-K answer generation Our proposal: use in-memory graph summary

to focus search on relevant parts of the graph avoid IO for rest of graph
6

Related Work

Keyword querying on graphs using precomputed info

Idea: Avoid search at query time, use only inverted list merge Drawbacks include high space overhead (ObjectRank, EKSO) Several algorithms (Nodine, Buchsbaum, etc) that give worst case guarantees, but require excessive replication Several algorithms (Shekhar, Chang etc) But all depend on properties specific to road networks (large diameter, near planarity etc) For visualization (Lieserson, Buchsbaum etc.) For web graph computations (Raghavan and Garcia-M.)

External memory graph traversal

Shortest path computation in external memory graphs

Hierarchical clustering

2-level graph clustering

Supernode Graph

Inner node

Edge weights: wt(S1 S2): min{wt(i j): i S1, j S2}

Strawman: 2-Phase Search

First-Attempt Algorithm:

Phase 1 : Search on supernode graph to get top-k results (containing supernodes)

Using any search algorithm

Expand all supernodes from supernode results Phase 2 : Search on this expanded component of graph to get final top-k results Top-k on expanded component may not be top-k on full graph Experiments show poor recall
9

Doesnt quite work:

Multi-Granular Graph Representation

Original supernode graph is in-memory Some supernodes are expanded

i.e. their contents are fetched into cache

Multi-granular graph: a logical graph view containing

inner nodes from expanded supernodes unexpanded supernodes edges between these nodes Multi-granular graph evolves as execution proceeds, and supernodes get expanded
10

Search runs on resultant multi-granular graph

Multi-Granular Graph
S1 S4

Key:
S2

Supernode (unexpanded) Inner Node

Expanded Supernode
I - I edge S - I edge S - S edge

S3

Edge-weights:Supernode Innernode
wt(S j): wt(j S):

min{wt(i j): i S} symmetric to above

Iterative Expansion Search

top-k answers pure?

Expand supernodes
in top answers

Edges in top-k answers

12

Iterative Expansion (Cont.)

Any in-memory search algorithm can be used Iteration will terminate What if too many nodes are expanded?

Eviction of expanded nodes from MG graph

Can lead to non-convergence

Evict expanded nodes from cache, but retain in logical MG graph, re-fetch as required

Can cause thrashing (thrashing control possible)

Performance Evaluation (details later)

Significantly reduces IO compared to search using virtual memory BUT: High CPU cost due to multiple iterations, with each iteration starting search from scratch
13

Incremental Search

Motivation Repeated restarts of search in iterative search Basic Idea Search on multi-granular graph Expand supernode(s) in top answer Unlike Iterative Search

Update the state of the search algorithm when a supernode is expanded, and Continue search instead of restarting

State update depends on search algorithm

We present state update for backward expanding search (BANKS, ICDE02/VLDB05)

Backward Expanding Search

writes

authors

Soumen C.

Byron Dom

SPI Tree

SPI Tree

15

Backward Expanding Search

Based on Dijkstras single-source shortest path algorithm

One instance of Dijkstras algorithm per keyword Explored nodes: nodes for which shortest path already found Fringe nodes: unexplored nodes adjacent to explored nodes Shortest-Path Iterator Tree (SPI-Tree):

Tree containing explored and fringe nodes. Edge u v if (current) shortest path from u to keyword passes through v

More details in paper

Incremental Backward Search

Backward search run on multi-granular graph repeat

Find next best answer on current multi-granular graph If answer has supernodes expand supernode(s) Update the state of backward search, i.e. all SPI trees, to reflect state change of multi-granular graph due to expansion

until top-k answers on current multi-granular graph are pure answers

17

State Update on Supernode Expansion

S1

Result containing supernodes Supernode S1 to be expanded

SPI tree containing S1

Nodes Get Attached

1. 2.

Affected nodes get detached Inner-nodes get attached (as fringe nodes) to adjacent explored nodes based on shortest path to K1

3. Affected nodes get attached (as fringe nodes) to adjacent explored nodes based on shortest path to K1
19

Effect of Supernode Expansion

Differences from Dijkstra's shortest-path algorithm: For Explored nodes:

Path-costs of explored nodes may increase Explored nodes may become fringe nodes Incremental Expansion: Path-costs may increase or decrease

For Fringe nodes:

Invariant

SPI trees reflect shortest paths for explored nodes in current multi-granular graph

Theorem: Incremental backward expanding search generates correct top-k answers

Heuristics

Thrashing Control : Stop supernode expansion on cache full Use only parts of the graph already expanded for further search

Intra-supernode edge weight

details in paper Recall at or close to 100% for relevant answers, with heuristics, in our experiments (see paper for details)
21

Heuristics can affect recall

Experimental Setup

Clustering algorithm to create supernodes

Orthogonal to our work Experiments use Edge prioritized BFS (details in paper) Ongoing work: develop better clustering techniques echo 3 > /proc/sys/vm/drop caches Original Graph Size 99MB Supernode Graph Size 17MB Edges 8.5M Superedges 1.4M

All experiments done on cold cache

Dataset DBLP

IMDB

94MB

33MB

8M
1024 (7MB) 3510 (24MB)

2.8M

Default Cache size (Incr/Iter) Default Cache Size (VM, DBLP)

Default Cache Size (VM, IMDB)

5851 (40MB)
22

Algorithms Compared

Iterative Incremental Virtual Memory (VM) Search

Use same clustering as for supernode graph Fetch cluster into cache whenever a node is accessed

evicting LRU cluster if required gets Virtual Memory view

Search code unaware of clustering/caching

Sparse

SQL-based approach from Hristidis et al. [VLDB03] Not applicable to graphs without schema

used for comparison, on graphs derived from relational schema

Query Execution Time (top 10 results)

Query Execution Time (Seconds)

Bars: Iterative, Incremental and VM resp.

24

Query Execution Time (Last Relevant Result)

Query Execution Time (Seconds)

Iterative, Incremental, VM and Sparse resp.

25

Cache Misses for Different Cache Sizes

All VM

All Incr.

Note: Graphs in paper used wrong cache sizes for VM queries on IMDB (Q8,Q9, Q10 and Q12). Graph above shows corrected results, but there are no significant differences. 26

Conclusions

Graph summarization coupled with a multigranular graph representation shows promise for external memory graph search Ongoing/Future work

Applications in distributed memory graph search Improved clustering techniques Extending Incremental to bidirectional search and other graph search algorithms Testing on really large graphs

27

The End

Queries?

28

Minor Correction to Paper

Cache size (Incr/Iter)

1024 (7MB)

1536 (10.5MB)

2048 (14MB)

Cache Size (VM, DBLP)

3510 (24MB)
5851 (40MB)

4023 (27.5MB)
6363 (43.5MB)

4535 (31MB)
6875 (47MB)

For IMDB queries Q8-Q10,Q12, for the case of VMSearch, cache sizes from DBLP were inadvertently used earlier instead of the cache sizes shown above. Queries were rerun on the correct cache size, but there were no changes in the relative performance of Incremental versus VMSearch, on cache misses as well time taken.

29