accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: OpenTSDB
Date Mon, 12 May 2014 01:00:09 GMT
Possibly, but it would look different than Don described. It would be 
fairly easy to write data to an existing HBase instance from Accumulo 
(and one can probably assume the opposite to be true). Thus, Gets/Scans 
would be using the HBase API.

On 5/11/14, 8:30 PM, Mike Drob wrote:
> The replication interface might be an easy place to try and support this.
>
>
> On Sun, May 11, 2014 at 8:20 PM, Donald Miner <dminer@clearedgeit.com
> <mailto:dminer@clearedgeit.com>> wrote:
>
>     "Commands" like scan, put, create table, etc.
>
>     It would respond to hbase thrift and pretend it was hbase.... But it
>     is using accumulo behind the scenes. basically be a translation
>     layer. There are obviously some things that don't translate.
>
>     I presume you could do something across all of the big table
>     implementations.
>
>     On May 11, 2014, at 7:33 PM, David Medinets
>     <david.medinets@gmail.com <mailto:david.medinets@gmail.com>> wrote:
>
>>     Please define "hbase commands".
>>
>>
>>     On Sun, May 11, 2014 at 7:29 PM, Donald Miner
>>     <dminer@clearedgeit.com <mailto:dminer@clearedgeit.com>> wrote:
>>
>>         Crazy/bad idea I've had before.... we could develop a
>>         hbase->accumulo proxy that receives basic hbase commands and
>>         then writes out accumulo.
>>
>>         On May 11, 2014, at 4:57 PM, Eric Newton
>>         <eric.newton@gmail.com <mailto:eric.newton@gmail.com>> wrote:
>>
>>>         It is being maintained.  I have tried very hard not to modify
>>>         the core OpenTSDB to support it.  But, it would be nice if we
>>>         could define a storage-independent layer to which it could
>>>         adhere.
>>>
>>>         I don't believe the OTSDB team is interested, but a basic
>>>         scalable back-end abstraction would be nice.  As would a
>>>         standard java build environment, but that doesn't seem to be
>>>         wanted, either.
>>>
>>>         We could work towards a common storage abstraction, which
>>>         would be a reasonable request.
>>>
>>>         Zipkin does a good job of being storage independent.  I would
>>>         work towards their model.
>>>
>>>         -Eric
>>>
>>>         On May 11, 2014 10:28 AM, "Arshak Navruzyan"
>>>         <arshakn@gmail.com <mailto:arshakn@gmail.com>> wrote:
>>>
>>>             I noticed Eric Newton's opentsdb adapter for Accumulo.
>>>              Is this still being maintained?
>>>
>>>             https://github.com/ericnewton/accumulo-opentsdb
>>>
>>>             Also wondering if the StumbleUpon folks are willing to
>>>             merge it in as an alternative to HBase back end.
>>>
>>>             Thanks
>>>
>>>             Arshak
>>>
>>
>

Mime
View raw message