Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # user - Re: HBase - Secondary Index

Copy link to this message
Re: HBase - Secondary Index
Michel Segel 2013-01-09, 01:30
Can you provide a use case?
Sent from a remote device. Please excuse any typos...

Mike Segel

On Jan 8, 2013, at 6:30 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> Different use cases.
> For global point queries you want exactly what you said below.
> For range scans across many rows you want Anoop's design. As usually it depends.
> The tradeoff is bringing a lot of unnecessary data to the client vs having to contact each region (or at least each region server).
> -- Lars
> ________________________________
> From: Michael Segel <[EMAIL PROTECTED]>
> Sent: Tuesday, January 8, 2013 6:33 AM
> Subject: Re: HBase - Secondary Index
> So if you're using an inverted table / index why on earth are you doing it at the region level?
> I've tried to explain this to others over 6 months ago and its not really a good idea.
> You're over complicating this and you will end up creating performance bottlenecks when your secondary index is completely orthogonal to your row key.
> To give you an example...
> Suppose you're CCCIS and you have a large database of auto insurance claims that you've acquired over the years from your Pathways product.
> Your primary key would be a combination of the Insurance Company's ID and their internal claim ID for the individual claim.
> Your row would be all of the data associated to that claim.
> So now lets say you want to find the average cost to repair a front end collision of an S80 Volvo.
> The make and model of the car would be orthogonal to the initial key. This means that the result set containing insurance records for Front End collisions of S80 Volvos would be most likely evenly distributed across the cluster's regions.
> If you used a series of inverted tables, you would be able to use a series of get()s to get the result set from each index and then find their intersections. (Note that you could also put them in sort order so that the intersections would be fairly straight forward to find.
> Doing this at the region level isn't so simple.
> So I have to again ask why go through and over complicate things?
> Just saying...
> On Jan 7, 2013, at 7:49 AM, Anoop Sam John <[EMAIL PROTECTED]> wrote:
>> Hi,
>> It is inverted index based on column(s) value(s)
>> It will be region wise indexing. Can work when some one knows the rowkey range or NOT.
>> -Anoop-
>> ________________________________________
>> From: Mohit Anchlia [[EMAIL PROTECTED]]
>> Sent: Monday, January 07, 2013 9:47 AM
>> Subject: Re: HBase - Secondary Index
>> Hi Anoop,
>> Am I correct in understanding that this indexing mechanism is only
>> applicable when you know the row key? It's not an inverted index truly
>> based on the column value.
>> Mohit
>> On Sun, Jan 6, 2013 at 7:48 PM, Anoop Sam John <[EMAIL PROTECTED]> wrote:
>>> Hi Adrien
>>>                  We are making the consistency btw the main table and
>>> index table and the roll back mentioned below etc using the CP hooks. The
>>> current hooks were not enough for those though..  I am in the process of
>>> trying to contribute those new hooks, core changes etc now...  Once all are
>>> done I will be able to explain in details..
>>> -Anoop-
>>> ________________________________________
>>> From: Adrien Mogenet [[EMAIL PROTECTED]]
>>> Sent: Monday, January 07, 2013 2:00 AM
>>> Subject: Re: HBase - Secondary Index
>>> Nice topic, perhaps one of the most important for 2013 :-)
>>> I still don't get how you're ensuring consistency between index table and
>>> main table, without an external component (such as bookkeeper/zookeeper).
>>> What's the exact write path in your situation when inserting data ?
>>> (WAL/RegionObserver, pre/post put/WALedit...)
>>> The underlying question is about how you're ensuring that WALEdit in Index
>>> and Main tables are perfectly sync'ed, and how you 're able to rollback in