Sorry for the late reply. I was on vacation last 10 days. > For folks that haven't been following the issue some high-level "how it all > kinda works" would be helpful from the championing commiters; that's a long > doc to get through and grok :). How similar is this to the work currently > by the existing indexing implementations (huawei, Phoenix, ngdata)? The doc > doesn't really nail down the interactions, but instead just right in after > describing why SI should be added.
This is local indexing solution from Huawei, will compare it with Phoenix,ngdata and update the details in the doc. > for instance, the doc talks about how to implement indexing for > floats... That might be a default impl, but for use cases like Phoenix this > would break all our current encodings. I agree with you. This can be more pluggable. Actually we wanted to make use of ordered bytes currently supported in hbase. > IMHO, it would be valuable if the design considered both a global > indexing solution and a local indexing solution. Both are useful in > different circumstances. The global indexing design plus the > application integration points could be derived from Jesse's work with > his reference implementation in Phoenix - the global indexing code has > no Phoenix dependencies and clearly defined integration points. We are happy to do this, will go through the global indexing solution and the integrating points in Phoenix. I will discuss with you/Jesse for any help. Thanks. Rajeshbabu. ________________________________________ From: saint....@gmail.com [saint....@gmail.com] on behalf of Stack [st...@duboce.net] Sent: Thursday, January 09, 2014 10:45 PM To: HBase Dev List Cc: Sudarshan Kadambi Subject: Re: Design review: Secondary index support through coprocess On Thu, Jan 9, 2014 at 6:36 AM, Jesse Yates <jesse.k.ya...@gmail.com> wrote: > ... > > For folks that haven't been following the issue some high-level "how it all > kinda works" would be helpful from the championing commiters; that's a long > doc to get through and grok :). How similar is this to the work currently > by the existing indexing implementations (huawei, Phoenix, ngdata)? The doc > doesn't really nail down the interactions, but instead just right in after > describing why SI should be added. > +1 on the above sentiment for this or any other big feature. It would help get more folks involved in the reviewing process. St.Ack