hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michel Segel <michael_se...@hotmail.com>
Subject Re: HBase - Secondary Index
Date Wed, 09 Jan 2013 09:39:06 GMT

You haven't provided a use case...

You are defending a design without showing an example of how it its implemented.
Without a concrete example, it's impossible to determine if there is a design flaw in the
initial design.

Sorry, but I don't think that enough thought has been done...
I'm trying to understand your reasoning, but without a concrete example... It's kind of hard.

Sent from a remote device. Please excuse any typos...

Mike Segel

On Jan 8, 2013, at 9:22 PM, Anoop Sam John <anoopsj@huawei.com> wrote:

> Totally agree with Lars.  The design came up as per our usage and data distribution style
> Also the put performance we were not able to compromise. That is why the region collocation
based region based indexing design came :)
> Also as we are having the indexing and index usage every thing happening at server side,
there is no need for any change in the client part depending on what type of client u use.
Java code or REST APIs or any thing.  Also MR based parallel scans any thing can be comparably
easy I feel as there is absolutely no changes needed at client side.  :)
> As Anil said there will be pros and cons for every way and which one suits your usage,
needs to be adopted. :)
> -Anoop-
> ________________________________________
> From: anil gupta [anilgupta84@gmail.com]
> Sent: Wednesday, January 09, 2013 6:58 AM
> To: user@hbase.apache.org; lars hofhansl
> Subject: Re: HBase - Secondary Index
> +1 on Lars comment.
> Either the client gets the rowkey from secondary table and then gets the
> real data from Primary Table. ** OR ** Send the request to all the RS(or
> region) hosting a region of primary table.
> Anoop is using the latter mechanism. Both the mechanism have their pros and
> cons. IMO, there is no outright winner.
> ~Anil Gupta
> On Tue, Jan 8, 2013 at 4:30 PM, lars hofhansl <larsh@apache.org> 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.

View raw message