Why do you need to build an in-memory graph which you would want to read/write to? You could store the graph in HBase directly. As pointed out, HBase might not be the best suited for SPARQL queries, but its not impossible to do. Using the triples, you can form a graph that can be represented in HBase as an adjacency list. I've stored graphs with 16-17M nodes which was data equivalent to about 600M triples. And this was on a small cluster and could certainly scale way more than 16M graph nodes.
In case you are interested in working on SPARQL over HBase, we could collaborate on it... -ak Amandeep Khurana Computer Science Graduate Student University of California, Santa Cruz On Wed, Mar 31, 2010 at 11:56 AM, Andrew Purtell <apurt...@apache.org>wrote: > Hi Raffi, > > To read up on fundamentals I suggest Google's BigTable paper: > http://labs.google.com/papers/bigtable.html > > Detail on how HBase implements the BigTable architecture within the Hadoop > ecosystem can be found here: > > http://wiki.apache.org/hadoop/Hbase/HbaseArchitecture > http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html > > http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html > > Hope that helps, > > - Andy > > > From: Basmajian, Raffi <rbasmaj...@oppenheimerfunds.com> > > Subject: RE: Using SPARQL against HBase > > To: hbase-user@hadoop.apache.org, apurt...@apache.org > > Date: Wednesday, March 31, 2010, 11:42 AM > > If Hbase can't respond to SPARQL-like queries, then what type > > of query language can it respond to? In a traditional RDBMS > > database one would use SQL; so what is the counterpart query > > language with Hbase? > > > > >