hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: Data types stage 1 is ready for reivew
Date Fri, 12 Jul 2013 20:10:48 GMT
Did some chatting with Nick today.

I think it is really important to get this right, and for that we would
definitely need more eyes towards it. The current patch set is in a good
state to bolster the discussion.

The other important thing is that we should be dogfeeding this in HBase
proper before marking it stable and public. For that, I suggested that we
can start with converting our META row keys and data model to use this
infrastructure as a first complex use case.

Depending on the timeline, I can see that these patches can make into the
0.96 line (before 0.96.0 or even after), but not declared stable in 0.96


On Thu, Jul 11, 2013 at 12:16 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> Heya devs,
> I have two 90k patches I'd like to get some more eyes on. The first is the
> OrderedBytes patch, HBASE-8201 [0]. It is lightly analogous to the existing
> Bytes.toXXX methods, but implements order-preserving serialization
> strategies. Its encoding format can be inspected to determine the encoding
> used. The patch is nearing completion, so now's the time to add your
> concerns to RB [1]. The major outstanding issue with this patch is its use
> of ByteBuffers; there's concern about the amount of garbage that will be
> generated in tight loops. Our ByteRange was proposed as a mutable
> alternative. The other concern is performance of the encoding
> implementations. While performance is a consideration in this
> implementation, I've created a separate ticket [2] for evaluating and
> improving runtime performance. Please keep your attention on the on-disk
> formats and APIs this patch implements.
> The second is the Data Types API patch, HBASE-8693 [3]. It provides a
> user-extensible data type API and includes implementations of a number of
> simple types. Many of those types depend on the encoding provided by
> OrderedByes. It also provides a collection of "legacy" types, which all use
> the existing Bytes.toXXX methods. These are intended to ease the burden of
> transitioning an existing HBase application over to the new data types
> APIs. This patch is in an earlier stage, but it's conceptually quite simple
> so it should be easier to review. It's also available on RB [4].
> Thanks for your time and attention,
> Nick
> [0]: https://issues.apache.org/jira/browse/HBASE-8201
>  [1]: https://reviews.apache.org/r/11633/
> [2]: https://issues.apache.org/jira/browse/HBASE-8694
> [3]: https://issues.apache.org/jira/browse/HBASE-8693
> [4]: https://reviews.apache.org/r/12069/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message