hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Meil <doug.m...@explorysmedical.com>
Subject Re: Notes from HBase Types/Serialization Discussion
Date Thu, 07 Mar 2013 22:21:20 GMT


On 3/7/13 5:16 PM, "Stack" <stack@duboce.net> wrote:

>(I'm sending this for Doug Meil; he is having difficulty getting this up
>the dev list)
>Hi Devs-
>Notes from an HBase client conference call a few of us had yesterday.
> Attendees:  Enis, Nick D., James Taylor, Stack, LarsH, Doug Meil and Andy
>   - Discussion of Serialization Scheme Independent of Java
>      - After a short discussion, this is a very interesting idea but off
>      the table for the next 4-6 releases.
>      - E.g., would we have to invent serialization for C++ or Python
>      clients?  It's not a small undertaking.
>      - Nobody was aware of any other open source libraries that did this.
>   - Component Priority
>      - After a healthy discussion, the following priority emerged:
>   - 1) Serialized Types
>         - But focusing on Java.  Using some combination of Orderly and
>         Phoenix
>         - Nick/James to lead this.
>         - New Jira will be created for this effort, with sub-tasks for
>         follow-on tasks.
>      - 2) Utilities
>         - E.g., something akin to what HBASE-7221 was trying to achieve.
>          This might also be a documentation exercise on how to
>properly use Orderly
>         - I.e., utilities to build rowkeys (et al.) in code for use by
>         applications (I.e., not Hbase itself)
>         - Consensus on support for both FixedLength and VariableLength
>         rowkeys, to allow for faster scans especially in the former
>case.  But
>         still providing utilities for variable length keys because
>folks still use
>         things like URLs in rowkeys.
>      - 3) Schema
>         - Schema definitions of rowkeys and tables that could be
>         externalized to Hive, et al.
>      - HBase-Centric API
>      - With respect to Utilities and Schemas, there was consensus that
>      completely enveloping HTable is not the suggested path, but rather
>      should look for opportunities to improve the Get, Put, Scan
>interfaces with
>      Htable but make it less tedious with byte-array handling.
>   - HBASE-7221
>      - This will be closed as "won't fixed", but will be linked from
>      whatever the new Jira is as a related ticket.
>   - Agreeing To Something And Actually Doing It
>      - Stack proposed the novel idea of all of us agreeing to something
>      and then actually doing it, and there was consensus that this was a
>      idea.   :-)

View raw message