A Solution to the Supernode Problem
Join the DZone community and get the full member experience.
Join For Freein 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 powerlaw 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 realworld
peertopeer 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 peertopeer 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 peertopeer 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 twittersphere.
blueprints and vertex queries
blueprints is a java interface for graphbased software. various graph databases , inmemory graph engines , and batchanalytics 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 1to5
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 vertexcentric 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 vertexcentric indices for finegrained 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 personvertex named dan. 5 of those instances have vertexcentric 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
stargraphs
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/ vertexcentric 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 vertexcentric 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).invthe 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 inmemory, warmcache response times show a similar pattern (albeit relatively faster). the averaged results are plotted below where the yaxis 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 vertexcentric indices and the dark version is titan/berkeleydb with vertexcentric indices.
perhaps the most impressive result is the retrieval of dan’s 10 most recent tweets (blue). with vertexcentric 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 vertexcentric 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 vertexcentric 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, inmemory, getting all of dan’s coworkers and then sorting on
since
. the interested reader can explore the runtimes of such composite vertexcentric 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 25x faster retrievals for the presented
knows
/
likes
queries and up to 10,000x faster for the
tweets
query when vertexcentric 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 disklevel so only requisite data is actually fetched and brought into memory. vertexcentric 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 realtime big graph data ,” aurelius blog, august 2012.
authors
Published at DZone with permission of Marko Rodriguez, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments