You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@accumulo.apache.org by Arshak Navruzyan <ar...@gmail.com> on 2014/05/11 14:41:48 UTC
OpenTSDB
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
Re: OpenTSDB
Posted by Eric Newton <er...@gmail.com>.
I've only seen it from another user on the OpenTSDB mailing list. :-)
The hack to write to accumulo using OpenTSDB was to replace the hbase async
library. This trace indictes that it is still using the real hbase async
library.
You will want to ensure your OpenTSDB doesn't have this library in your
path, and just has the fake library that talks to accumulo.
-Eric
On Tue, Jun 3, 2014 at 7:04 PM, Arshak Navruzyan <ar...@gmail.com> wrote:
> Eric,
>
> Curious if you've seen this error before.
>
> Thanks,
>
> Arshak
>
> 2014-06-03 15:30:53,736 INFO [main] ZooKeeper: Initiating client
> connection, connectString=accumulo://root:secret@localhost:2181/ecluster
> sessionTimeout=5000 watcher=org.hbase.async.HBaseClient$ZKClient@6426f7af
>
> 2014-06-03 15:30:53,767 INFO [main] TSDB: Flushing compaction queue
>
> Exception in thread "main" java.lang.RuntimeException: Initialization
> failed
>
> at net.opentsdb.tools.TSDMain.main(TSDMain.java:182)
>
> Caused by: java.lang.IllegalArgumentException: Invalid path string
> "//root:secret@localhost:2181/ecluster" caused by empty node name
> specified @1
>
> at org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:99)
>
> at org.apache.zookeeper.ClientCnxn.<init>(ClientCnxn.java:363)
>
> at org.apache.zookeeper.ClientCnxn.<init>(ClientCnxn.java:327)
>
> at org.apache.zookeeper.ZooKeeper.<init>(ZooKeeper.java:383)
>
> at org.hbase.async.HBaseClient$ZKClient.connectZK(HBaseClient.java:3004)
>
> at
> org.hbase.async.HBaseClient$ZKClient.getDeferredRoot(HBaseClient.java:2909)
>
> at org.hbase.async.HBaseClient.locateRegion(HBaseClient.java:1871)
>
> at org.hbase.async.HBaseClient.sendRpcToRegion(HBaseClient.java:1703)
>
> at
> org.hbase.async.HBaseClient.ensureTableFamilyExists(HBaseClient.java:947)
>
> at org.hbase.async.HBaseClient.ensureTableExists(HBaseClient.java:967)
>
> at net.opentsdb.core.TSDB.checkNecessaryTablesExist(TSDB.java:317)
>
> at net.opentsdb.tools.TSDMain.main(TSDMain.java:147)
>
>
> On Sun, May 11, 2014 at 1:57 PM, Eric Newton <er...@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" <ar...@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
>>>
>>
>
Re: OpenTSDB
Posted by Arshak Navruzyan <ar...@gmail.com>.
Eric,
Curious if you've seen this error before.
Thanks,
Arshak
2014-06-03 15:30:53,736 INFO [main] ZooKeeper: Initiating client
connection, connectString=accumulo://root:secret@localhost:2181/ecluster
sessionTimeout=5000 watcher=org.hbase.async.HBaseClient$ZKClient@6426f7af
2014-06-03 15:30:53,767 INFO [main] TSDB: Flushing compaction queue
Exception in thread "main" java.lang.RuntimeException: Initialization failed
at net.opentsdb.tools.TSDMain.main(TSDMain.java:182)
Caused by: java.lang.IllegalArgumentException: Invalid path string
"//root:secret@localhost:2181/ecluster" caused by empty node name specified
@1
at org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:99)
at org.apache.zookeeper.ClientCnxn.<init>(ClientCnxn.java:363)
at org.apache.zookeeper.ClientCnxn.<init>(ClientCnxn.java:327)
at org.apache.zookeeper.ZooKeeper.<init>(ZooKeeper.java:383)
at org.hbase.async.HBaseClient$ZKClient.connectZK(HBaseClient.java:3004)
at
org.hbase.async.HBaseClient$ZKClient.getDeferredRoot(HBaseClient.java:2909)
at org.hbase.async.HBaseClient.locateRegion(HBaseClient.java:1871)
at org.hbase.async.HBaseClient.sendRpcToRegion(HBaseClient.java:1703)
at org.hbase.async.HBaseClient.ensureTableFamilyExists(HBaseClient.java:947)
at org.hbase.async.HBaseClient.ensureTableExists(HBaseClient.java:967)
at net.opentsdb.core.TSDB.checkNecessaryTablesExist(TSDB.java:317)
at net.opentsdb.tools.TSDMain.main(TSDMain.java:147)
On Sun, May 11, 2014 at 1:57 PM, Eric Newton <er...@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" <ar...@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
>>
>
Re: OpenTSDB
Posted by Josh Elser <jo...@gmail.com>.
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
> <ma...@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 <ma...@gmail.com>> wrote:
>
>> Please define "hbase commands".
>>
>>
>> On Sun, May 11, 2014 at 7:29 PM, Donald Miner
>> <dminer@clearedgeit.com <ma...@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 <ma...@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 <ma...@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
>>>
>>
>
Re: OpenTSDB
Posted by Mike Drob <md...@mdrob.com>.
The replication interface might be an easy place to try and support this.
On Sun, May 11, 2014 at 8:20 PM, Donald Miner <dm...@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 <da...@gmail.com>
> wrote:
>
> Please define "hbase commands".
>
>
> On Sun, May 11, 2014 at 7:29 PM, Donald Miner <dm...@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 <er...@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" <ar...@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
>>>
>>
>
Re: OpenTSDB
Posted by Donald Miner <dm...@clearedgeit.com>.
I've thought about this a lot actually (and finally have some time to sit
down and type it out). This plays into my larger idea of an automated
hbase->accumulo suite. A system that moves data from one to the other is
one piece, the other piece is letting existing hbase applications hit
accumulo instead. Anyways...
The most efficient thing to do is to have Accumulo tablet servers speak
something that a native hbase client can talk to. What's going on in a
client is pretty complex, so it's not going to be as easy as writing some
interfaces. I think.
The proxy idea is okay, but I think we'll see some performance problems.
The other option is to do it client side, which would mean the applications
would need to be rebuilt with our "special" APIs that look the same as
before, but really behind the scenes are translating it to an accumulo
call. Maybe they'd have to change an import or something.
Maybe there is a larger project here, something like a bigtable API that
Cassandra, HBase, and Accumulo all can sign on to supporting. Or it is just
client-side code. Not sure. Then something like OpenTSDB or zipkin would
just write to the bigtable API and you wouldn't have to write new code.
Lot of options... not sure which one i like. Sorry for rambling.
-d
On Sun, May 11, 2014 at 8:56 PM, Donald Miner <dm...@clearedgeit.com>wrote:
> We are having a hackathon the day of during the conference. Not exclusive
> to the idea of having a separate hack day the day before. I know some of us
> are participating in the conference and can't participate in the hackathon.
>
>
>
> On May 11, 2014, at 8:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> Don,
>
> Yeah I was thinking covering most of the bigtable implementations at the
> source level would be an easy place to start.
>
> Any interest in organizing a hack day near the Accumulo Summit to try to
> get an initial implementation done?
>
> --
> Sean
> On May 11, 2014 7:28 PM, "Donald Miner" <dm...@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 <da...@gmail.com>
>> wrote:
>>
>> Please define "hbase commands".
>>
>>
>> On Sun, May 11, 2014 at 7:29 PM, Donald Miner <dm...@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 <er...@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" <ar...@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
>>>>
>>>
>>
--
Donald Miner
Chief Technology Officer
ClearEdge IT Solutions, LLC
Cell: 443 799 7807
www.clearedgeit.com
Re: OpenTSDB
Posted by Donald Miner <dm...@clearedgeit.com>.
We are having a hackathon the day of during the conference. Not exclusive to the idea of having a separate hack day the day before. I know some of us are participating in the conference and can't participate in the hackathon.
> On May 11, 2014, at 8:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> Don,
>
> Yeah I was thinking covering most of the bigtable implementations at the source level would be an easy place to start.
>
> Any interest in organizing a hack day near the Accumulo Summit to try to get an initial implementation done?
>
> --
> Sean
>
>> On May 11, 2014 7:28 PM, "Donald Miner" <dm...@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 <da...@gmail.com> wrote:
>>>
>>> Please define "hbase commands".
>>>
>>>
>>>> On Sun, May 11, 2014 at 7:29 PM, Donald Miner <dm...@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 <er...@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" <ar...@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
Re: OpenTSDB
Posted by Sean Busbey <bu...@cloudera.com>.
Don,
Yeah I was thinking covering most of the bigtable implementations at the
source level would be an easy place to start.
Any interest in organizing a hack day near the Accumulo Summit to try to
get an initial implementation done?
--
Sean
On May 11, 2014 7:28 PM, "Donald Miner" <dm...@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 <da...@gmail.com>
> wrote:
>
> Please define "hbase commands".
>
>
> On Sun, May 11, 2014 at 7:29 PM, Donald Miner <dm...@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 <er...@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" <ar...@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
>>>
>>
>
Re: OpenTSDB
Posted by Donald Miner <dm...@clearedgeit.com>.
"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 <da...@gmail.com> wrote:
>
> Please define "hbase commands".
>
>
>> On Sun, May 11, 2014 at 7:29 PM, Donald Miner <dm...@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 <er...@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" <ar...@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
>
Re: OpenTSDB
Posted by Sean Busbey <bu...@cloudera.com>.
I've started looking at something like this for the major read/write APIs
for HBase and Accumulo in Kite.
One difference is that I'd prefer to eventually get to a common API that
can be backed by either HBase 0.98+ or Accumulo.
--
Sean
On May 11, 2014 6:34 PM, "David Medinets" <da...@gmail.com> wrote:
> Please define "hbase commands".
>
>
> On Sun, May 11, 2014 at 7:29 PM, Donald Miner <dm...@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 <er...@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" <ar...@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
>>>
>>
>
Re: OpenTSDB
Posted by David Medinets <da...@gmail.com>.
Please define "hbase commands".
On Sun, May 11, 2014 at 7:29 PM, Donald Miner <dm...@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 <er...@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" <ar...@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
>>
>
Re: OpenTSDB
Posted by Donald Miner <dm...@clearedgeit.com>.
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 <er...@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" <ar...@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
Re: OpenTSDB
Posted by Eric Newton <er...@gmail.com>.
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" <ar...@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
>