Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # user >> HBase type support


+
Nick Dimiduk 2013-03-13, 16:42
+
David Koch 2013-03-14, 16:51
+
Michel Segel 2013-03-15, 12:25
+
Nick Dimiduk 2013-03-15, 17:06
+
Michel Segel 2013-03-15, 22:35
+
Nick Dimiduk 2013-03-19, 20:34
+
Nick Dimiduk 2013-03-15, 17:11
+
James Taylor 2013-03-15, 17:55
+
Nick Dimiduk 2013-03-15, 17:57
+
lars hofhansl 2013-03-16, 05:45
+
Michel Segel 2013-03-16, 12:18
+
Michel Segel 2013-03-16, 12:26
+
Andrew Purtell 2013-03-16, 12:59
+
Michael Segel 2013-03-17, 16:13
+
Andrew Purtell 2013-03-17, 17:12
+
Amit Sela 2013-03-17, 17:32
+
Michel Segel 2013-03-18, 12:02
+
Doug Meil 2013-03-18, 19:16
+
Michael Segel 2013-03-19, 00:42
+
Mohamed Ibrahim 2013-03-17, 17:24
+
ramkrishna vasudevan 2013-03-18, 03:01
+
Michel Segel 2013-03-18, 11:51
+
Nick Dimiduk 2013-03-19, 20:35
+
Jonathan Hsieh 2013-03-18, 23:54
Copy link to this message
-
Re: HBase type support
yup. Why break a good thing? ;-)

On Mar 18, 2013, at 6:54 PM, Jonathan Hsieh <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]
>>> 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 <[EMAIL PROTECTED]>
>>>> 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 <[EMAIL PROTECTED]>
>>>>> 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
> // [EMAIL PROTECTED]
+
Nick Dimiduk 2013-03-19, 20:38
+
Nick Dimiduk 2013-03-19, 20:30