You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by Sergey Soldatov <se...@gmail.com> on 2017/05/10 23:22:14 UTC
HBase 2.0 future integration.
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.
Thanks,
Sergey
Re: HBase 2.0 future integration.
Posted by Andrew Purtell <an...@gmail.com>.
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 <el...@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
>>
Re: HBase 2.0 future integration.
Posted by Josh Elser <el...@apache.org>.
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
>