hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Segel <michael_se...@hotmail.com>
Subject Re: HBase type support
Date Tue, 19 Mar 2013 00:31:39 GMT
yup. Why break a good thing? ;-)

On Mar 18, 2013, at 6:54 PM, Jonathan Hsieh <jon@cloudera.com> wrote:

> +1.  I really don't want to add typing specific information into hbase core
> -- howver, having buliding blocks, plugins, and extra metadata manage it
> seems quite reasonable to me.
> 
> There are many many games that can be played to encode data and enforcing
> typing at the hbase level as opposed to library. (ex: putting in structs
> that have fields with ints as opposed to having tons of cols with ints in
> them, or how opentsdb encodes time stamps, etc..).
> 
> Jon.
> 
> On Fri, Mar 15, 2013 at 10:45 PM, lars hofhansl <larsh@apache.org> wrote:
> 
>> I think generally we should keep HBase a byte[] based key value store.
>> What we should add to HBase are tools that would allow client side apps
>> (or libraries) to built functionality on top of plain HBase.
>> 
>> Serialization that maintains a correct semantic sort order is important as
>> a building block, so is code that can build up correctly serialized and
>> sortable compound keys, as well as hashing algorithms.
>> 
>> Where I would draw the line is adding types to HBase itself. As long as
>> one can write a client, or Filters, or Coprocessors with the tools provided
>> by HBase we're good. Higher level functionality can then be built of on top
>> of HBase.
>> 
>> 
>> For example, maybe we need to add better access API to the HBase WAL in
>> order to have an external library implement idempotent transactions (which
>> can be used to implement 2ndary indexes).
>> Maybe some other primitives have to be exposed in order to allow an
>> external library to implement full transactions.
>> Or we might need a statistics framework (such as the one that Jesse is
>> working on).
>> 
>> These are all building blocks that do not presume specific access patterns
>> or clients, but can be used to implement them.
>> 
>> 
>> As usual, just my $0.02.
>> 
>> -- Lars
>> 
>> 
>> 
>> ________________________________
>> From: Nick Dimiduk <ndimiduk@gmail.com>
>> To: user@hbase.apache.org
>> Sent: Friday, March 15, 2013 10:57 AM
>> Subject: Re: HBase type support
>> 
>> I'm talking about MD5, SHA1, etc. It's something explicitly mentioned
>> in HBASE-7221.
>> 
>> On Fri, Mar 15, 2013 at 10:55 AM, James Taylor <jtaylor@salesforce.com
>>> wrote:
>> 
>>> Hi Nick,
>>> What do you mean by "hashing algorithms"?
>>> Thanks,
>>> James
>>> 
>>> 
>>> On 03/15/2013 10:11 AM, Nick Dimiduk wrote:
>>> 
>>>> Hi David,
>>>> 
>>>> Native support for a handful of hashing algorithms has also been
>>>> discussed.
>>>> Do you think these should be supported directly, as opposed to using a
>>>> fixed-length String or fixed-length byte[]?
>>>> 
>>>> Thanks,
>>>> Nick
>>>> 
>>>> On Thu, Mar 14, 2013 at 9:51 AM, David Koch <ogdude@googlemail.com>
>>>> wrote:
>>>> 
>>>> Hi Nick,
>>>>> 
>>>>> As an HBase user I would welcome this addition. In addition to the
>>>>> proposed
>>>>> list of datatypes A UUID/GUID type would also be nice to have.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> /David
>>>>> 
>>>>> 
>>>>> On Wed, Mar 13, 2013 at 5:42 PM, Nick Dimiduk <ndimiduk@gmail.com>
>>>>> wrote:
>>>>> 
>>>>> Hi all,
>>>>>> 
>>>>>> I'd like to draw your attention to HBASE-8089. The desire is to add
>> type
>>>>>> support to HBase. There are two primary objectives: make the lives
of
>>>>>> developers building on HBase easier, and facilitate better tools
on
>> top
>>>>>> 
>>>>> of
>>>>> 
>>>>>> HBase. Please chime in with any feature suggestions you think we've
>>>>>> 
>>>>> missed
>>>>> 
>>>>>> in initial conversations.
>>>>>> 
>>>>>> Thanks,
>>>>>> -n
>>>>>> 
>>>>>> [0]: https://issues.apache.org/**jira/browse/HBASE-8089<
>> https://issues.apache.org/jira/browse/HBASE-8089>
>>>>>> 
>>>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com


Mime
View raw message