hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Coprocessor Increments
Date Thu, 10 Oct 2013 03:43:12 GMT
John:
Suppose 'California-**12346' is the start key of region 1 and 'California-**
95424' is the start key of region 2. You can choose 'California-**12346#total'
to be the row key where increment is done for region 1 and
'California-**95424#total'
to be the row key where increment is done for region 2.

w.r.t. verification of whether given row key is indeed inside the hosting
region, see the following:

  void checkRow(final byte [] row, String op) throws IOException {

    if (!rowIsInRange(getRegionInfo(), row)) {

      throw new WrongRegionException("Requested row out of range for " +

          op + " on HRegion " + this + ", startKey='" +

Cheers


On Wed, Oct 9, 2013 at 8:26 PM, John Weatherford <
john.weatherford@telescope.tv> wrote:

> First, Thank you everyone for the quick response.
>
> Ted:
>   The custom split policy could be an interesting solution. Regarding the
> other option you sent, if I pull the end row key, I could construct an end
> key, but if I suffix the row key with the end key of the region, would that
> actually solve my problem? In the contrived case, wouldn't the suffixed key
> now be "California-total-California-**12346"  and the other region's
> counter would be "California-total-California-**95424" and both of these
> keys would actually end up on the second region since the sorting of the
> keys would impose that "California-t*" comes after "California-[1-9]".
>
> Part of the question is that I don't understand if calling
> incrementColumnValue() on the region will always execute on the region
> called, regardles of rowkey. If so, what happens when those regions are
> merged?
>
> Thanks again for the help!
>
>
> On Wed 09 Oct 2013 07:43:34 PM PDT, Ted Yu wrote:
>
>> bq. 'California-total' row in each region
>>
>> Of course such row key needs to be suffixed with either start or end key
>> of
>> the corresponding region.
>>
>>
>> On Wed, Oct 9, 2013 at 7:39 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>>
>>  John:
>>> Looks like you need a 'California-total' row in each region.
>>>
>>> Custom Split Policy can help you achieve that, see 9.7.4.1 in:
>>> http://hbase.apache.org/book.**html#d0e6541<http://hbase.apache.org/book.html#d0e6541>
>>>
>>> Cheers
>>>
>>>
>>> On Wed, Oct 9, 2013 at 7:28 PM, Vladimir Rodionov <
>>> vrodionov@carrieriq.com
>>>
>>>> wrote:
>>>>
>>>
>>>  Contrived Example
>>>>>>
>>>>>
>>>>  Insert rowkey "California-12345" triggers a coprocessor to call
>>>>>> incrementColumnValue() with a rowkey of "California-total"  all on
>>>>>>
>>>>> Region 1.
>>>>
>>>>  This would likely be on an insert on the same region. But as the table
>>>>>> grows, this secondary insert could end up on another region. If it
is
>>>>>> confined, then suppose we later insert "California-95424" which still
>>>>>> triggers a call to incrementColumnValue() with a rowkey of
>>>>>> "California-total" all on Region 2.
>>>>>>
>>>>>
>>>>  Are we now left with two rowkeys of "California-total"? One on each
>>>>>> region server? If so, what happens if these two regions are compacted
>>>>>> into one?
>>>>>>
>>>>>
>>>>  Best regards,
>>>>>>
>>>>>
>>>> Nope, Your "California-total" will migrate to Region 2 after region
>>>> split
>>>> is complete.
>>>>
>>>> Vladimir Rodionov
>>>> Principal Platform Engineer
>>>> Carrier IQ, www.carrieriq.com
>>>> e-mail: vrodionov@carrieriq.com
>>>>
>>>> ______________________________**__________
>>>>
>>>> Confidentiality Notice:  The information contained in this message,
>>>> including any attachments hereto, may be confidential and is intended
>>>> to be
>>>> read only by the individual or entity to whom this message is
>>>> addressed. If
>>>> the reader of this message is not the intended recipient or an agent or
>>>> designee of the intended recipient, please note that any review, use,
>>>> disclosure or distribution of this message or its attachments, in any
>>>> form,
>>>> is strictly prohibited.  If you have received this message in error,
>>>> please
>>>> immediately notify the sender and/or Notifications@carrieriq.com and
>>>> delete or destroy any copy of this message and its attachments.
>>>>
>>>>
>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message