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 <[email protected]> wrote: > Totally agree with Lars. The design came up as per our usage and data > distribution style etc. > 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 [[email protected]] > Sent: Wednesday, January 09, 2013 6:58 AM > To: [email protected]; 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 <[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. >
