You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by jeff saremi <je...@hotmail.com> on 2017/01/30 19:03:45 UTC
Performance: HBase Native Java Client versus Thrift Java client
I'd like to understand if there are any considerations on why one would use thrift versus the direct client?
I was told that Thrift server allow key-caching which would result in faster key-to-regionserver queries as opposed to getting that from the Hbase master nodes. It would also alleviate the load on the master.
At the same time, we know if going through Thrift would add to the latency since it's an indirect way of getting at data.
thanks
Jeff
Re: Performance: HBase Native Java Client versus Thrift Java client
Posted by Josh Elser <el...@apache.org>.
Bingo. Thrift also has the perk of supporting clients written in a
variety of languages.
jeff saremi wrote:
> Got it.
>
> It looks like there's some benefit in having a Thrift server to serve one-off requests, for which creation of a single Hbase client may be a little too expensive.
>
>
> ________________________________
> From: Josh Elser<el...@apache.org>
> Sent: Monday, January 30, 2017 1:05 PM
> To: user@hbase.apache.org
> Subject: Re: Performance: HBase Native Java Client versus Thrift Java client
>
> Right you are, Jeff. The Master is just coordinating where these Regions
> are hosted (among other things...).
>
> Clients would be caching the mapping of which RegionServers is hosting a
> Region. Typically this information does not change often. In the case
> that it does change, the client can often react very quickly to this.
>
> Unless you have some use-case where your Java client is not long-lived,
> the Thrift server would always be overhead on top of what the HBase
> client itself would do. The Thrift server is just wrapping the HBase
> client you'd use in your own Java application and exposing it in a
> different manner.
>
> jeff saremi wrote:
>> Thanks Josh
>>
>> I made a mistake in mentioning the master. It looks like the client contacts the Region Server which holds the Meta table.
>>
>> Of a query into the meta table to get the RegionServer for a given key, it wasn't clear to me what was being cached on the client? Also on the same topic, is a Thrift server assisting this process in any shape or form? to make its presence necessary?
>>
>> Is there anything else that the Thrift server might be contributing to positively?
>>
>>
>>
>> ________________________________
>> From: Josh Elser<el...@apache.org>
>> Sent: Monday, January 30, 2017 11:57 AM
>> To: user@hbase.apache.org
>> Subject: Re: Performance: HBase Native Java Client versus Thrift Java client
>>
>> Would recommend that you brush up on your understanding of the HBase
>> architecture.
>>
>> Clients do not receive table data from the HBase Master at any point.
>> This is purely a RegionServer operation.
>>
>> http://hbase.apache.org/book.html#_architecture
> Apache HBase (tm) Reference Guide<http://hbase.apache.org/book.html#_architecture>
> hbase.apache.org
> Supported. In the context of Apache HBase, /supported/ means that HBase is designed to work in the way described, and deviation from the defined behavior or ...
>
>
>> jeff saremi wrote:
>>> I'd like to understand if there are any considerations on why one would use thrift versus the direct client?
>>>
>>> I was told that Thrift server allow key-caching which would result in faster key-to-regionserver queries as opposed to getting that from the Hbase master nodes. It would also alleviate the load on the master.
>>>
>>> At the same time, we know if going through Thrift would add to the latency since it's an indirect way of getting at data.
>>>
>>>
>>> thanks
>>>
>>> Jeff
>>>
>
Re: Performance: HBase Native Java Client versus Thrift Java client
Posted by jeff saremi <je...@hotmail.com>.
Got it.
It looks like there's some benefit in having a Thrift server to serve one-off requests, for which creation of a single Hbase client may be a little too expensive.
________________________________
From: Josh Elser <el...@apache.org>
Sent: Monday, January 30, 2017 1:05 PM
To: user@hbase.apache.org
Subject: Re: Performance: HBase Native Java Client versus Thrift Java client
Right you are, Jeff. The Master is just coordinating where these Regions
are hosted (among other things...).
Clients would be caching the mapping of which RegionServers is hosting a
Region. Typically this information does not change often. In the case
that it does change, the client can often react very quickly to this.
Unless you have some use-case where your Java client is not long-lived,
the Thrift server would always be overhead on top of what the HBase
client itself would do. The Thrift server is just wrapping the HBase
client you'd use in your own Java application and exposing it in a
different manner.
jeff saremi wrote:
> Thanks Josh
>
> I made a mistake in mentioning the master. It looks like the client contacts the Region Server which holds the Meta table.
>
> Of a query into the meta table to get the RegionServer for a given key, it wasn't clear to me what was being cached on the client? Also on the same topic, is a Thrift server assisting this process in any shape or form? to make its presence necessary?
>
> Is there anything else that the Thrift server might be contributing to positively?
>
>
>
> ________________________________
> From: Josh Elser<el...@apache.org>
> Sent: Monday, January 30, 2017 11:57 AM
> To: user@hbase.apache.org
> Subject: Re: Performance: HBase Native Java Client versus Thrift Java client
>
> Would recommend that you brush up on your understanding of the HBase
> architecture.
>
> Clients do not receive table data from the HBase Master at any point.
> This is purely a RegionServer operation.
>
> http://hbase.apache.org/book.html#_architecture
Apache HBase (tm) Reference Guide<http://hbase.apache.org/book.html#_architecture>
hbase.apache.org
Supported. In the context of Apache HBase, /supported/ means that HBase is designed to work in the way described, and deviation from the defined behavior or ...
>
> jeff saremi wrote:
>> I'd like to understand if there are any considerations on why one would use thrift versus the direct client?
>>
>> I was told that Thrift server allow key-caching which would result in faster key-to-regionserver queries as opposed to getting that from the Hbase master nodes. It would also alleviate the load on the master.
>>
>> At the same time, we know if going through Thrift would add to the latency since it's an indirect way of getting at data.
>>
>>
>> thanks
>>
>> Jeff
>>
>
Re: Performance: HBase Native Java Client versus Thrift Java client
Posted by Josh Elser <el...@apache.org>.
Right you are, Jeff. The Master is just coordinating where these Regions
are hosted (among other things...).
Clients would be caching the mapping of which RegionServers is hosting a
Region. Typically this information does not change often. In the case
that it does change, the client can often react very quickly to this.
Unless you have some use-case where your Java client is not long-lived,
the Thrift server would always be overhead on top of what the HBase
client itself would do. The Thrift server is just wrapping the HBase
client you'd use in your own Java application and exposing it in a
different manner.
jeff saremi wrote:
> Thanks Josh
>
> I made a mistake in mentioning the master. It looks like the client contacts the Region Server which holds the Meta table.
>
> Of a query into the meta table to get the RegionServer for a given key, it wasn't clear to me what was being cached on the client? Also on the same topic, is a Thrift server assisting this process in any shape or form? to make its presence necessary?
>
> Is there anything else that the Thrift server might be contributing to positively?
>
>
>
> ________________________________
> From: Josh Elser<el...@apache.org>
> Sent: Monday, January 30, 2017 11:57 AM
> To: user@hbase.apache.org
> Subject: Re: Performance: HBase Native Java Client versus Thrift Java client
>
> Would recommend that you brush up on your understanding of the HBase
> architecture.
>
> Clients do not receive table data from the HBase Master at any point.
> This is purely a RegionServer operation.
>
> http://hbase.apache.org/book.html#_architecture
>
> jeff saremi wrote:
>> I'd like to understand if there are any considerations on why one would use thrift versus the direct client?
>>
>> I was told that Thrift server allow key-caching which would result in faster key-to-regionserver queries as opposed to getting that from the Hbase master nodes. It would also alleviate the load on the master.
>>
>> At the same time, we know if going through Thrift would add to the latency since it's an indirect way of getting at data.
>>
>>
>> thanks
>>
>> Jeff
>>
>
Re: Performance: HBase Native Java Client versus Thrift Java client
Posted by jeff saremi <je...@hotmail.com>.
Thanks Josh
I made a mistake in mentioning the master. It looks like the client contacts the Region Server which holds the Meta table.
Of a query into the meta table to get the RegionServer for a given key, it wasn't clear to me what was being cached on the client? Also on the same topic, is a Thrift server assisting this process in any shape or form? to make its presence necessary?
Is there anything else that the Thrift server might be contributing to positively?
________________________________
From: Josh Elser <el...@apache.org>
Sent: Monday, January 30, 2017 11:57 AM
To: user@hbase.apache.org
Subject: Re: Performance: HBase Native Java Client versus Thrift Java client
Would recommend that you brush up on your understanding of the HBase
architecture.
Clients do not receive table data from the HBase Master at any point.
This is purely a RegionServer operation.
http://hbase.apache.org/book.html#_architecture
jeff saremi wrote:
> I'd like to understand if there are any considerations on why one would use thrift versus the direct client?
>
> I was told that Thrift server allow key-caching which would result in faster key-to-regionserver queries as opposed to getting that from the Hbase master nodes. It would also alleviate the load on the master.
>
> At the same time, we know if going through Thrift would add to the latency since it's an indirect way of getting at data.
>
>
> thanks
>
> Jeff
>
Re: Performance: HBase Native Java Client versus Thrift Java client
Posted by Josh Elser <el...@apache.org>.
Would recommend that you brush up on your understanding of the HBase
architecture.
Clients do not receive table data from the HBase Master at any point.
This is purely a RegionServer operation.
http://hbase.apache.org/book.html#_architecture
jeff saremi wrote:
> I'd like to understand if there are any considerations on why one would use thrift versus the direct client?
>
> I was told that Thrift server allow key-caching which would result in faster key-to-regionserver queries as opposed to getting that from the Hbase master nodes. It would also alleviate the load on the master.
>
> At the same time, we know if going through Thrift would add to the latency since it's an indirect way of getting at data.
>
>
> thanks
>
> Jeff
>