Re: Async get
I haven't heard that there will be an async client for HBase (but I'd love to be corrected). On Fri, Oct 20, 2017 at 11:05 AM, Karan Mehta <karanmeht...@gmail.com> wrote: > That is coming up in HBase 2.0 AFAIK. You can try out AsyncHBase ( > https://github.com/OpenTSDB/asynchbase/) till HBase 1.3, although it has > limited capabilities. > ᐧ > > On Fri, Oct 13, 2017 at 10:17 AM, Flavio Pompermaier <pomperma...@okkam.it > > wrote: > >> I totally agree. An official HBase async client would be awesome >> >> On 6 Oct 2017 08:08, "Jonathan Leech" <jonat...@gmail.com> wrote: >> >> I agree here but will go farther. Hbase needs an asynchronous api that >> goes further than its current capability, for example like building lamda >> functions in the client tier that execute in a java streams manner. Being >> able to run mapping functions, aggregations, etc without needing >> coprocessors would be a big win. If Hbase doesn’t do it, the next thing >> will. >> >> On Oct 5, 2017, at 11:31 AM, James Taylor <jamestay...@apache.org> wrote: >> >> I do think it would be good for Phoenix to have a netty-based async means >> of interacting with the server. We've found that to really drive down >> latency for a parallelized query over a big cluster, you have to have a >> ridiculously large thread pool on the client side (4000 threads for cluster >> with 100s of nodes). A netty-based means of interacting would allow us to >> drive down the latency without resorting to this (though this is pure >> conjecture at this point - we might run into other, unknown scaling >> constraints through an async API). Asynchbase, however, has a lot of >> restrictions in terms of how you can interact with the server. If it could >> become part of HBase and support the full wire protocol, then it might be >> an option. >> >> Thanks, >> James >> >> On Thu, Oct 5, 2017 at 7:00 AM, Flavio Pompermaier <pomperma...@okkam.it> >> wrote: >> >>> Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, >>> what do you think? >>> >>> On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew <kl...@apache.org> wrote: >>> >>>> Wrapping a thread-blocking call in a Future makes it asynchronous, but >>>> does not turn it into a non-blocking call. >>>> >>>> https://www.google.ca/amp/blog.colinbreck.com/calling-blocki >>>> ng-code-there-is-no-free-lunch/amp/ >>>> >>>> On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbe...@gmail.com> >>>> wrote: >>>> >>>>> Wrap the call in a Future. You're home. >>>>> >>>>> On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestay...@apache.org> >>>>> wrote: >>>>> >>>>>> Hi Flavio, >>>>>> Phoenix supports JDBC. The implementation may do gets, scans, etc., >>>>>> but it's completely transparent to the user. >>>>>> Thanks, >>>>>> James >>>>>> >>>>>> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier < >>>>>> pomperma...@okkam.it> wrote: >>>>>> >>>>>>> Hi to all, >>>>>>> does Phoenix support async get? I can't find anything about this.. >>>>>>> >>>>>>> Best, >>>>>>> Flavio >>>>>>> >>>>>> >>>>>> >>> >> >> >
Re: Async get
That is coming up in HBase 2.0 AFAIK. You can try out AsyncHBase ( https://github.com/OpenTSDB/asynchbase/) till HBase 1.3, although it has limited capabilities. ᐧ On Fri, Oct 13, 2017 at 10:17 AM, Flavio Pompermaier <pomperma...@okkam.it> wrote: > I totally agree. An official HBase async client would be awesome > > On 6 Oct 2017 08:08, "Jonathan Leech" <jonat...@gmail.com> wrote: > > I agree here but will go farther. Hbase needs an asynchronous api that > goes further than its current capability, for example like building lamda > functions in the client tier that execute in a java streams manner. Being > able to run mapping functions, aggregations, etc without needing > coprocessors would be a big win. If Hbase doesn’t do it, the next thing > will. > > On Oct 5, 2017, at 11:31 AM, James Taylor <jamestay...@apache.org> wrote: > > I do think it would be good for Phoenix to have a netty-based async means > of interacting with the server. We've found that to really drive down > latency for a parallelized query over a big cluster, you have to have a > ridiculously large thread pool on the client side (4000 threads for cluster > with 100s of nodes). A netty-based means of interacting would allow us to > drive down the latency without resorting to this (though this is pure > conjecture at this point - we might run into other, unknown scaling > constraints through an async API). Asynchbase, however, has a lot of > restrictions in terms of how you can interact with the server. If it could > become part of HBase and support the full wire protocol, then it might be > an option. > > Thanks, > James > > On Thu, Oct 5, 2017 at 7:00 AM, Flavio Pompermaier <pomperma...@okkam.it> > wrote: > >> Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, >> what do you think? >> >> On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew <kl...@apache.org> wrote: >> >>> Wrapping a thread-blocking call in a Future makes it asynchronous, but >>> does not turn it into a non-blocking call. >>> >>> https://www.google.ca/amp/blog.colinbreck.com/calling-blocki >>> ng-code-there-is-no-free-lunch/amp/ >>> >>> On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbe...@gmail.com> >>> wrote: >>> >>>> Wrap the call in a Future. You're home. >>>> >>>> On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestay...@apache.org> >>>> wrote: >>>> >>>>> Hi Flavio, >>>>> Phoenix supports JDBC. The implementation may do gets, scans, etc., >>>>> but it's completely transparent to the user. >>>>> Thanks, >>>>> James >>>>> >>>>> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier < >>>>> pomperma...@okkam.it> wrote: >>>>> >>>>>> Hi to all, >>>>>> does Phoenix support async get? I can't find anything about this.. >>>>>> >>>>>> Best, >>>>>> Flavio >>>>>> >>>>> >>>>> >> > >
Re: Async get
I totally agree. An official HBase async client would be awesome On 6 Oct 2017 08:08, "Jonathan Leech" <jonat...@gmail.com> wrote: I agree here but will go farther. Hbase needs an asynchronous api that goes further than its current capability, for example like building lamda functions in the client tier that execute in a java streams manner. Being able to run mapping functions, aggregations, etc without needing coprocessors would be a big win. If Hbase doesn’t do it, the next thing will. On Oct 5, 2017, at 11:31 AM, James Taylor <jamestay...@apache.org> wrote: I do think it would be good for Phoenix to have a netty-based async means of interacting with the server. We've found that to really drive down latency for a parallelized query over a big cluster, you have to have a ridiculously large thread pool on the client side (4000 threads for cluster with 100s of nodes). A netty-based means of interacting would allow us to drive down the latency without resorting to this (though this is pure conjecture at this point - we might run into other, unknown scaling constraints through an async API). Asynchbase, however, has a lot of restrictions in terms of how you can interact with the server. If it could become part of HBase and support the full wire protocol, then it might be an option. Thanks, James On Thu, Oct 5, 2017 at 7:00 AM, Flavio Pompermaier <pomperma...@okkam.it> wrote: > Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, > what do you think? > > On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew <kl...@apache.org> wrote: > >> Wrapping a thread-blocking call in a Future makes it asynchronous, but >> does not turn it into a non-blocking call. >> >> https://www.google.ca/amp/blog.colinbreck.com/calling-blocki >> ng-code-there-is-no-free-lunch/amp/ >> >> On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbe...@gmail.com> >> wrote: >> >>> Wrap the call in a Future. You're home. >>> >>> On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestay...@apache.org> >>> wrote: >>> >>>> Hi Flavio, >>>> Phoenix supports JDBC. The implementation may do gets, scans, etc., but >>>> it's completely transparent to the user. >>>> Thanks, >>>> James >>>> >>>> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier < >>>> pomperma...@okkam.it> wrote: >>>> >>>>> Hi to all, >>>>> does Phoenix support async get? I can't find anything about this.. >>>>> >>>>> Best, >>>>> Flavio >>>>> >>>> >>>> >
Re: Async get
I agree here but will go farther. Hbase needs an asynchronous api that goes further than its current capability, for example like building lamda functions in the client tier that execute in a java streams manner. Being able to run mapping functions, aggregations, etc without needing coprocessors would be a big win. If Hbase doesn’t do it, the next thing will. > On Oct 5, 2017, at 11:31 AM, James Taylor <jamestay...@apache.org> wrote: > > I do think it would be good for Phoenix to have a netty-based async means of > interacting with the server. We've found that to really drive down latency > for a parallelized query over a big cluster, you have to have a ridiculously > large thread pool on the client side (4000 threads for cluster with 100s of > nodes). A netty-based means of interacting would allow us to drive down the > latency without resorting to this (though this is pure conjecture at this > point - we might run into other, unknown scaling constraints through an async > API). Asynchbase, however, has a lot of restrictions in terms of how you can > interact with the server. If it could become part of HBase and support the > full wire protocol, then it might be an option. > > Thanks, > James > >> On Thu, Oct 5, 2017 at 7:00 AM, Flavio Pompermaier <pomperma...@okkam.it> >> wrote: >> Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, >> what do you think? >> >>> On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew <kl...@apache.org> wrote: >>> Wrapping a thread-blocking call in a Future makes it asynchronous, but does >>> not turn it into a non-blocking call. >>> >>> https://www.google.ca/amp/blog.colinbreck.com/calling-blocking-code-there-is-no-free-lunch/amp/ >>> >>>> On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbe...@gmail.com> >>>> wrote: >>>> Wrap the call in a Future. You're home. >>>> >>>> >>>>> On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestay...@apache.org> wrote: >>>>> Hi Flavio, >>>>> Phoenix supports JDBC. The implementation may do gets, scans, etc., but >>>>> it's completely transparent to the user. >>>>> Thanks, >>>>> James >>>>> >>>>>> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier >>>>>> <pomperma...@okkam.it> wrote: >>>>>> Hi to all, >>>>>> does Phoenix support async get? I can't find anything about this.. >>>>>> >>>>>> Best, >>>>>> Flavio >>>>> >> >
Re: Async get
I do think it would be good for Phoenix to have a netty-based async means of interacting with the server. We've found that to really drive down latency for a parallelized query over a big cluster, you have to have a ridiculously large thread pool on the client side (4000 threads for cluster with 100s of nodes). A netty-based means of interacting would allow us to drive down the latency without resorting to this (though this is pure conjecture at this point - we might run into other, unknown scaling constraints through an async API). Asynchbase, however, has a lot of restrictions in terms of how you can interact with the server. If it could become part of HBase and support the full wire protocol, then it might be an option. Thanks, James On Thu, Oct 5, 2017 at 7:00 AM, Flavio Pompermaier <pomperma...@okkam.it> wrote: > Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, > what do you think? > > On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew <kl...@apache.org> wrote: > >> Wrapping a thread-blocking call in a Future makes it asynchronous, but >> does not turn it into a non-blocking call. >> >> https://www.google.ca/amp/blog.colinbreck.com/calling-blocki >> ng-code-there-is-no-free-lunch/amp/ >> >> On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbe...@gmail.com> >> wrote: >> >>> Wrap the call in a Future. You're home. >>> >>> On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestay...@apache.org> >>> wrote: >>> >>>> Hi Flavio, >>>> Phoenix supports JDBC. The implementation may do gets, scans, etc., but >>>> it's completely transparent to the user. >>>> Thanks, >>>> James >>>> >>>> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier < >>>> pomperma...@okkam.it> wrote: >>>> >>>>> Hi to all, >>>>> does Phoenix support async get? I can't find anything about this.. >>>>> >>>>> Best, >>>>> Flavio >>>>> >>>> >>>> >
Re: Async get
Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, what do you think? On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew <kl...@apache.org> wrote: > Wrapping a thread-blocking call in a Future makes it asynchronous, but > does not turn it into a non-blocking call. > > https://www.google.ca/amp/blog.colinbreck.com/calling- > blocking-code-there-is-no-free-lunch/amp/ > > On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbe...@gmail.com> > wrote: > >> Wrap the call in a Future. You're home. >> >> On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestay...@apache.org> wrote: >> >>> Hi Flavio, >>> Phoenix supports JDBC. The implementation may do gets, scans, etc., but >>> it's completely transparent to the user. >>> Thanks, >>> James >>> >>> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier <pomperma...@okkam.it >>> > wrote: >>> >>>> Hi to all, >>>> does Phoenix support async get? I can't find anything about this.. >>>> >>>> Best, >>>> Flavio >>>> >>> >>>
Re: Async get
Wrapping a thread-blocking call in a Future makes it asynchronous, but does not turn it into a non-blocking call. https://www.google.ca/amp/blog.colinbreck.com/calling-blocking-code-there-is-no-free-lunch/amp/ On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbe...@gmail.com> wrote: > Wrap the call in a Future. You're home. > > On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestay...@apache.org> wrote: > >> Hi Flavio, >> Phoenix supports JDBC. The implementation may do gets, scans, etc., but >> it's completely transparent to the user. >> Thanks, >> James >> >> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier <pomperma...@okkam.it> >> wrote: >> >>> Hi to all, >>> does Phoenix support async get? I can't find anything about this.. >>> >>> Best, >>> Flavio >>> >> >>
Re: Async get
Hi Flavio, Phoenix supports JDBC. The implementation may do gets, scans, etc., but it's completely transparent to the user. Thanks, James On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier <pomperma...@okkam.it> wrote: > Hi to all, > does Phoenix support async get? I can't find anything about this.. > > Best, > Flavio >
