Just out of curiosity, > The secondary index is stored in table "B" as rowkey B --> > family:<rowkey > A> what is rowkey B here? > 1. Scan the secondary table by using prefix filter and startRow. How is the startRow determined for every query ?
Regards Ram > -----Original Message----- > From: Anoop Sam John [mailto:anoo...@huawei.com] > Sent: Thursday, October 25, 2012 10:15 AM > To: user@hbase.apache.org > Subject: RE: Best technique for doing lookup with Secondary Index > > >I build the secondary table "B" using a prePut RegionObserver. > > Anil, > In prePut hook u call HTable#put()? Why use the network calls > from server side here then? can not handle it from client alone? You > can have a look at Lily project. Thoughts after seeing ur idea on put > and scan.. > > -Anoop- > ________________________________________ > From: anil gupta [anilgupt...@gmail.com] > Sent: Thursday, October 25, 2012 3:10 AM > To: user@hbase.apache.org > Subject: Best technique for doing lookup with Secondary Index > > Hi All, > > I am using HBase 0.92.1. I have created a secondary index on table "A". > Table A stores immutable data. I build the secondary table "B" using a > prePut RegionObserver. > > The secondary index is stored in table "B" as rowkey B --> > family:<rowkey > A> . "<rowkey A>" is the column qualifier. Every row in B will only on > have one column and the name of that column is the rowkey of A. So the > value is blank. As per my understanding, accessing column qualifier is > faster than accessing value. Please correct me if i am wrong. > > > HBase Querying approach: > 1. Scan the secondary table by using prefix filter and startRow. > 2. Do a batch get on primary table by using HTable.get(List<Get>) > method. > > The above approach for retrieval works fine but i was wondering it > there is > a better approach. I was planning to try out doing the retrieval using > coprocessors. > Have anyone tried using coprocessors? I would appreciate if others can > share their experience with secondary index for HBase queries. > > -- > Thanks & Regards, > Anil Gupta=
