A Solution to the Supernode Problem

in graph theory and network science , a “supernode” is a vertex with a disproportionately high number of incident edges. while supernodes are rare in natural graphs (as statistically demonstrated with power-law degree distributions), they show up frequently during graph analysis. the reason being is that supernodes are connected to so many other vertices that they exist on numerous paths in the graph. therefore, an arbitrary traversal is likely to touch a supernode. in graph computing, supernodes can lead to system performance problems. fortunately, for property graphs , there is a theoretical and applied solution to this problem.

supernodes in the real-world

peer-to-peer file sharing

at the turn of the millenium, online file sharing was being supported by services like napster and gnutella . unlike napster, gnutella is a true peer-to-peer system in that it has no central file index. instead, a client’s search is sent to its adjacent clients. if those clients don’t have the file, then the request propagates to their adjacent clients, so forth and so on. as in any natural graph, a supernode is only a few steps away. therefore, in many peer-to-peer networks, supernode clients are quickly inundated with search requests and in turn, a dos is effected.

social network celebrities

president barack obama currently has 21,322,866 followers on twitter . when obama tweets, that tweet must register in the activity streams of 21+ million accounts. the barack obama vertex is considered a supernode. as an opposing example, when stephen mallette tweets, only 59 streams need to be updated. twitter realizes this discrepancy and maintains different mechanisms for handling “the obamas” (i.e. the celebrities) and “the stephens” (i.e. the plebeians) of the twitter-sphere.

blueprints and vertex queries

blueprints is a java interface for graph-based software. various graph databases , in-memory graph engines , and batch-analytics frameworks make use of blueprints. in june 2012, blueprints 2.x was released with support for “ vertex queries .” a vertex query is best explained with an example.

suppose there is a vertex named dan. incident to dan are 1,110 edges. these edges denote the people dan knows (10 edges), the things he likes (100 edges), and the tweets he has tweeted (1000 edges). if dan wants a list of all the people he knows and incident edges are not indexed by label, then dan would have to iterate through all 1,110 edges to find the 10 people he knew. however, if dan’s edges are indexed by edge label, then a lookup into a hash on knows would immediately yield the 10 people — o(n) vs. o(1) , where n is the number of edges incident to dan.

the idea of partitioning edges by discriminating qualities can be taken a step further in property graphs . property graphs support key/value pairs on vertices and edges. for example, a knows -edge can have a type -property with possible values of “work,” “family,” and “favorite” and a since property specifying when the relationship began. similarly, likes -edges can have a 1-to-5 rating -property and tweet -edges can have a time stamp denoting when the tweet was tweeted. blueprints’ query allows the developer to specify contraints on the incident edges to be retrieved. for example, to get all of dan’s highly rated items, the following blueprints code is evaluated.

dan.query().labels("likes").interval("rating",4,6).vertices()

titan and vertex-centric indices

blueprints only provides the interface for representing vertex queries. it is up to the underlying graph system to use the specified constraints to their advantage. the distributed graph database titan makes extensive use of vertex-centric indices for fine-grained retrieval of edge data from both disk and memory. to demonstrate the effectiveness of these indices, a benchmark is provided using titan/ berkeleydb (an acid variant of titan — see titan’s storage overview ).

10 titan/berkeleydb instances are created with a person-vertex named dan. 5 of those instances have vertex-centric indices, and 5 do not. each of the 5 instances per type have a variable number of edges incident to dan. these numbers are provided below.

total incident edges	knows -edges	likes -edges	tweets -edges
111	1	10	100
1,110	10	100	1000
11,100	100	1000	10000
111,000	1000	10000	100000
1,110,000	10000	100000	1000000

the gremlin /groovy script to generate the aforementioned star-graphs is provided below, where i is the variable defining the size of the resultant graph.

g = titanfactory.open('/tmp/supernode')
// index configuration snippet goes here for titan w/ vertex-centric indices
g.createkeyindex('name',vertex.class)
g.addvertex([name:'dan'])
  
r = new random(100)
types = ['work','family','favorite']
(1..i).each{g.addedge(g.v('name','dan').next(),g.addvertex(),'knows',[type:types.get(r.nextint(3)),since:it]); stoptx(g,it)}
(1..(i*10)).each{g.addedge(g.v('name','dan').next(),g.addvertex(),'likes',[rating:r.nextint(5)]); stoptx(g,it)}
(1..(i*100)).each{g.addedge(g.v('name','dan').next(),g.addvertex(),'tweets',[time:it]); stoptx(g,it)}

for the 5 titan/berkeleydb instances with vertex-centric indices, the following code fragment was evaluated. this code defines the indices (see titan’s type configurations ).

type = g.maketype().name('type').simple().functional(false).datatype(string.class).makepropertykey()
since = g.maketype().name('since').simple().functional(false).datatype(integer.class).makepropertykey()
rating = g.maketype().name('rating').simple().functional(false).datatype(integer.class).makepropertykey()
time = g.maketype().name('time').simple().functional(false).datatype(integer.class).makepropertykey()
g.maketype().name('knows').primarykey(type,since).makeedgelabel()
g.maketype().name('likes').primarykey(rating).makeedgelabel()
g.maketype().name('tweets').primarykey(time).makeedgelabel()

next, three traversals rooted at dan are presented. the first gets all the people dan knows of a particular randomly chosen type (e.g. family members). the second returns all of the things that dan has highly rated (i.e. 4 or 5 star ratings). the third retrieves dan’s 10 most recent tweets. finally, note that gremlin compiles each expression to an appropriate vertex query (see gremlin’s traversal optimizations ).

g.v('name','dan').oute('knows').has('type',types.get(r.nextint(3)).inv
g.v('name','dan').oute('likes').interval('rating',4,6).inv
g.v('name','dan').oute('tweets').has('time',t.gt,(i*100)-10).inv

the traversals above were each run 25 times with the database restarted after each query in order to demonstrate response times with cold jvm caches. note that in-memory, warm-cache response times show a similar pattern (albeit relatively faster). the averaged results are plotted below where the y-axis is on a log scale . the green, red, and blue colors denote the first, second and third queries, respectively. moreover, there is a light and a dark version of each color. the light version is titan/berkeleydb without vertex-centric indices and the dark version is titan/berkeleydb with vertex-centric indices.

perhaps the most impressive result is the retrieval of dan’s 10 most recent tweets (blue). with vertex-centric indices (dark blue), as the number of dan’s tweets grow to 1 million, the time it takes to get the top 10 stays constant at around 1.5 milliseconds. without indices, this query grows proportionate to the amount of data and ultimately requires 13 seconds to complete (light blue). that is a 4 orders of magnitude difference in response time for the same result set . this example demonstrates how useful vertex-centric indices are for activity stream -type systems.

the plot on the right displays the number of vertices returned by each query over each graph size. as expected, the number of tweets stays constant at 10 while the number of knows and likes vertices retrieved grows proportionate to the growing graphs. while the examples on the same graph (with and without indices) return the same data, getting to that data is faster with vertex-centric indices.

finally, titan also supports composite key indices. the graph construction code fragment previous assigns a primary key of both type and since to knows -edges. therefore, retrieving dan’s 10 most recent coworkers is more efficient than, in-memory, getting all of dan’s coworkers and then sorting on since . the interested reader can explore the runtimes of such composite vertex-centric queries by augmenting the provided code snippets.

conclusion

a supernode is only a problem when the discriminating information between edges is ignored. if all edges are treated equally, then linear o(n) searches through the incident edge set of a vertex are required. however when indices and sort orders are used, o(log(n)) and o(1) lookups can be achieved. the presented results demonstrate 2-5x faster retrievals for the presented knows / likes queries and up to 10,000x faster for the tweets query when vertex-centric indices are employed. now consider when a traversal is more than a single hop. the runtimes compound in a combinatoric manner. compounding at 1 millisecond vs 10 seconds leads to astronomical differences in overall traversal runtime.

the graph database titan can scale to support 100s of billions of edges (via apache cassandra and hbase ). vertices with a million+ incident edges are frequent in such massive graphs. in the world of big graph data, it is important to store and retrieve data from disk and memory efficiently. with titan, edge filtering is pushed down to the disk-level so only requisite data is actually fetched and brought into memory. vertex-centric queries and indices overcome the supernode problem by intelligently leveraging the label and property information of the edges incident to a vertex.

related material

rodriguez, m.a., broecheler, m., “ titan: the rise of big graph data ,” public lecture at jive software, palo alto, 2012.

broecheler, m., larocque, d., rodriguez, m.a., “ titan provides real-time big graph data ,” aurelius blog, august 2012.

authors