phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: HBase 2.0 future integration.
Date Mon, 15 May 2017 03:27:20 GMT
HBase itself declares 0.98 EOL. There is nobody planning to make more releases of it. I was
the former RM of this code line so am pretty sure about that, although this is open source,
anyone can be lobbied to make another. There is already reason and certain eventuality regarding
leaving it behind.  I advise moving on.


> On May 14, 2017, at 8:17 PM, Josh Elser <elserj@apache.org> wrote:
> 
> 
> 
> Sergey Soldatov wrote:
>> Hi,
>> 
>> Well, HBase 2.0 will be released in the near future and we need to think
>> about adopting Phoenix to it. I tried to do that and already feel
>> uncomfortable with the amount of changes related to existing and potential
>> problems. There are the list of problems I'm aware at the moment:
>> 1. Deprecated API. No surprise that most of the deprecated 0.9x API was
>> removed. Such as:
>>    a. 'add' method for Put. We use it all across the code and tests.
>>    b. HBaseAdmin replaced with Admin.
>>    c. HTableInterface removed.
>>    d. Public API should use Cell instead of KeyValue
>>    e. Delete.deleteColumn =>  Delete.addColumn.
>>    f. There are some other small changes that requires small modification
>> (like .batch now requires             an array for the result instead of
>> returning it)
>> 2.  Due the shading stuff RPC callback need to use a new API
>> from CoprocessorRpcUtils.
>> 3.  No more "new HTable(...)". To get Table we have to create unmanaged
>> connection and use .getTable.
>> 
>> As for a potential problems:
>> 1. new AM makes me worry in terms of the support for local indexes during
>> split/merge.
>> 2.  Tephra uses deprecated API as well, so it requires similar changes.
>> 
>> 
>> So, here are my ideas :
>> 1. start with something that we can change right now (API changes that
>> would work with all supported versions of HBase) to minimize the work and
>> amount of changes when 2.0 is released.
>>  2. Decide what we are going to do with 0.98 support. Whether we plan to
>> EOL it, or as an alternative we may create some kind of driver to HBase, so
>> we will be able to keep all changes  for  different versions of HBase at a
>> single place.
> 
> Dropping 0.98 support for Phoenix is the "obvious" idea to me to help move both projects
forward.
> 
> I think if, in this process, we can identify areas in HBase which could use "firming
up" WRT server-side stability, that would also be a welcome change.
> 
>> Thanks,
>> Sergey
>> 

Mime
View raw message