"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 <[email protected]> wrote: > > Please define "hbase commands". > > >> On Sun, May 11, 2014 at 7:29 PM, Donald Miner <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >
