Thats right.. We dont delete nodes and want easy navigability, so adjacent lists work out well.
On Mon, Apr 5, 2010 at 7:53 AM, Tim Robertson <[email protected]>wrote: > I think he means his table looked like the one on: > http://en.wikipedia.org/wiki/Adjacency_list > > I suspect it means that you can navigate the graph nicely, but a > consequence being you might need to update a lot of rows when a node > is deleted for example. > > > On Mon, Apr 5, 2010 at 4:42 PM, Basmajian, Raffi > <[email protected]> wrote: > > Can you elaborate on what you mean by "adjacent list?" How did you set > > that up? > > > > > > > > -----Original Message----- > > From: Amandeep Khurana [mailto:[email protected]] > > Sent: Wednesday, March 31, 2010 5:42 PM > > To: [email protected] > > Subject: Re: Using SPARQL against HBase > > > > I didnt do queries over triples. It was essentially a graph stored as an > > adjacency list and used gets and scans for all the work. > > > > Andrew, if Trend is interested too, we can make this a serious project. > > > > > > Amandeep Khurana > > Computer Science Graduate Student > > University of California, Santa Cruz > > > > > > On Wed, Mar 31, 2010 at 1:08 PM, Basmajian, Raffi < > > [email protected]> wrote: > > > >> With all of those triples stored in Hbase, how did you query the data? > >> Using the Hbase Get/Scan api? > >> > >> -----Original Message----- > >> From: Amandeep Khurana [mailto:[email protected]] > >> Sent: Wednesday, March 31, 2010 3:30 PM > >> To: [email protected]; [email protected] > >> Subject: Re: Using SPARQL against HBase > >> > >> 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 > >> <[email protected]>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.htm > >> > l > >> > > >> > http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead > >> > -l > >> > og.html > >> > > >> > Hope that helps, > >> > > >> > - Andy > >> > > >> > > From: Basmajian, Raffi <[email protected]> > >> > > Subject: RE: Using SPARQL against HBase > >> > > To: [email protected], [email protected] > >> > > 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? > >> > > >> > > >> > > >> > > >> > > >> > >> > >> ---------------------------------------------------------------------- > >> -------- This e-mail transmission may contain information that is > >> proprietary, privileged and/or confidential and is intended > >> exclusively for the person(s) to whom it is addressed. Any use, > >> copying, retention or disclosure by any person other than the intended > > > >> recipient or the intended recipient's designees is strictly > >> prohibited. If you are not the intended recipient or their designee, > >> please notify the sender immediately by return e-mail and delete all > >> copies. OppenheimerFunds may, at its sole discretion, monitor, review, > > > >> retain and/or disclose the content of all email communications. > >> > >> ====================================================================== > >> ======== > >> > >> > > > > > ------------------------------------------------------------------------------ > > This e-mail transmission may contain information that is proprietary, > privileged and/or confidential and is intended exclusively for the person(s) > to whom it is addressed. Any use, copying, retention or disclosure by any > person other than the intended recipient or the intended recipient's > designees is strictly prohibited. If you are not the intended recipient or > their designee, please notify the sender immediately by return e-mail and > delete all copies. OppenheimerFunds may, at its sole discretion, monitor, > review, retain and/or disclose the content of all email communications. > > > ============================================================================== > > > > >
