hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <saint....@gmail.com>
Subject Re: Scanning .META. with start/stop row
Date Mon, 18 Jul 2011 20:15:26 GMT
That would be better yes

Good stuff



On Jul 18, 2011, at 9:42, Todd Lipcon <todd@cloudera.com> wrote:

> Yea, it used to throw some IllegalArgumentException. Now, I guess it just
> gives the wrong result.
> 
> Should shell compensate or should we fix the underlying issue? It seems we
> could probably tweak the comparator to deal with the case when one of the
> comparison operands has no commas.
> 
> -Todd
> 
> On Mon, Jul 18, 2011 at 9:34 AM, Stack <stack@duboce.net> wrote:
> 
>> Ugh.  I should have remembered this.  Shell should probably compensate
>> when the target of scan is one of the catalog tables.  Good on you
>> Todd,
>> St.Ack
>> 
>> On Sun, Jul 17, 2011 at 11:22 PM, Lars George <lars.george@gmail.com>
>> wrote:
>>> Wow, awesome Todd:
>>> 
>>> hbase(main):004:0> scan '.META.', {STARTROW => 'testtable2', LIMIT =>
1}
>>> ROW                                 COLUMN+CELL
>>> 2011-07-17T23:20:45.480-0700: 58.760: [GC 58.760: [ParNew:
>> 19136K->2112K(19136K), 0.0098980 secs] 21990K->6759K(83008K), 0.0099430
>> secs] [Times: user=0.05 sys=0.00, real=0.01 secs]
>>> TestTable,,1294648777729.1c1644f4a column=info:regioninfo,
>> timestamp=1294648777898, value=REGION => {NAME =>
>> 'TestTable,,1294648777729.1c
>>> 1304442d9c8483a6d167d48.           1644f4a1304442d9c8483a6d167d48.',
>> STARTKEY => '', ENDKEY => '', ENCODED => 1c1644f4a1304442d9c8483a6d1
>>>                                   67d48, TABLE => {{NAME => 'TestTable',
>> FAMILIES => [{NAME => 'col1', BLOOMFILTER => 'NONE', REPLICATIO
>>>                                   N_SCOPE => '0', COMPRESSION => 'NONE',
>> VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '65536', IN_
>>>                                   MEMORY => 'false', BLOCKCACHE =>
>> 'true'}]}}
>>> ...
>>> 1 row(s) in 0.3990 seconds
>>> 
>>> hbase(main):005:0> scan '.META.', {STARTROW => 'testtable2,,', LIMIT =>
>> 1}
>>> ROW                                 COLUMN+CELL
>>> testtable2,,1310754563673.d720f2ae column=info:regioninfo,
>> timestamp=1310754573539, value=REGION => {NAME =>
>> 'testtable2,,1310754563673.d
>>> 6a4aec4fce746f6a9c1376e3.          720f2ae6a4aec4fce746f6a9c1376e3.',
>> STARTKEY => '', ENDKEY => 'row-10', ENCODED => d720f2ae6a4aec4fce74
>>>                                   6f6a9c1376e3, TABLE => {{NAME =>
>> 'testtable2', FAMILIES => [{NAME => 'family', BLOOMFILTER => 'NONE',
>>>                                   REPLICATION_SCOPE => '0', COMPRESSION
>> => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '6
>>>                                   5536', IN_MEMORY => 'false',
>> BLOCKCACHE => 'true'}]}}
>>> ...
>>> 1 row(s) in 0.0440 seconds
>>> 
>>> This also makes the STOPROW work:
>>> 
>>> hbase(main):006:0> scan '.META.', {STARTROW => 'testtable2,,', STOPROW
=>
>> 'testtable3'}
>>> ROW                                 COLUMN+CELL
>>> 0 row(s) in 0.0220 seconds
>>> 
>>> hbase(main):007:0> scan '.META.', {STARTROW => 'testtable2,,', STOPROW
=>
>> 'testtable3,,'}
>>> ROW                                 COLUMN+CELL
>>> testtable2,,1310754563673.d720f2ae column=info:regioninfo,
>> timestamp=1310754573539, value=REGION => {NAME =>
>> 'testtable2,,1310754563673.d
>>> 6a4aec4fce746f6a9c1376e3.          720f2ae6a4aec4fce746f6a9c1376e3.',
>> STARTKEY => '', ENDKEY => 'row-10', ENCODED => d720f2ae6a4aec4fce74
>>>                                   6f6a9c1376e3, TABLE => {{NAME =>
>> 'testtable2', FAMILIES => [{NAME => 'family', BLOOMFILTER => 'NONE',
>>>                                   REPLICATION_SCOPE => '0', COMPRESSION
>> => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '6
>>>                                   5536', IN_MEMORY => 'false',
>> BLOCKCACHE => 'true'}]}}
>>> ...
>>> testtable2,row-10,1310754563677.81 column=info:regioninfo,
>> timestamp=1310754573667, value=REGION => {NAME =>
>> 'testtable2,row-10,131075456
>>> 73e0623a0f82c5b308790737900b60.
>> 3677.8173e0623a0f82c5b308790737900b60.', STARTKEY => 'row-10', ENDKEY =>
>> 'row-20', ENCODED => 8173e062
>>>                                   3a0f82c5b308790737900b60, TABLE =>
>> {{NAME => 'testtable2', FAMILIES => [{NAME => 'family', BLOOMFILTER
>>>                                    => 'NONE', REPLICATION_SCOPE => '0',
>> COMPRESSION => 'NONE', VERSIONS => '3', TTL => '2147483647', BLO
>>>                                   CKSIZE => '65536', IN_MEMORY =>
>> 'false', BLOCKCACHE => 'true'}]}}
>>> ...
>>> 
>>> So it is caused by the same issue. Should be fixed, right?
>>> 
>>> Lars
>>> 
>>> 
>>> On Jul 18, 2011, at 4:36 AM, Todd Lipcon wrote:
>>> 
>>>> Try with STARTROW => "testtable2,,"?
>>>> I seem to remember some weirdness about the start/stop row having to
>> have
>>>> the meta "format" with commas, etc
>>>> 
>>>> -Todd
>>>> 
>>>> On Fri, Jul 15, 2011 at 2:01 PM, Stack <stack@duboce.net> wrote:
>>>> 
>>>>> On Fri, Jul 15, 2011 at 11:40 AM, Lars George <lars.george@gmail.com>
>>>>> wrote:
>>>>>> Using the start row, it prints the entire META.
>>>>> 
>>>>> Starting with the STARTROW.
>>>>> 
>>>>>> Setting a stop row it does
>>>>>> not print a single row:
>>>>> 
>>>>> 
>>>>> Yeah. I see that too in 0.90.3.
>>>>> 
>>>>> St.Ack
>>>>> 
>>>>>> 
>>>>>> hbase(main):003:0> scan '.META.', { STARTROW => 'testtable2',
STOPROW
>> =>
>>>>>> 'testtable3' }
>>>>>> ROW                                 COLUMN+CELL
>>>>>> 
>>>>>> 0 row(s) in 0.0220 seconds
>>>>>> 
>>>>>> I have a testtable2 in this case. Am I stuffing up the syntax?
>>>>>> 
>>>>>> Lars
>>>>>> 
>>>>>> On Fri, Jul 15, 2011 at 8:36 PM, Stack <stack@duboce.net> wrote:
>>>>>> 
>>>>>>> Passing 'STARTROW'  in 0.90.3 seems to work.  What you see Lars?
>>>>>>> St.Ack
>>>>>>> 
>>>>>>> On Fri, Jul 15, 2011 at 11:31 AM, Lars George <lars.george@gmail.com
>>> 
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I am on 0.90.1 (CDH3u0) but noticed that on trunk as well:
doing
>> scan
>>>>> of
>>>>>>>> .META. using a start and stop row does not work. The start
row does
>>>>>>> nothing,
>>>>>>>> i.e. all is shown, and setting the stop row is the opposite,
i.e.
>>>>> nothing
>>>>>>> is
>>>>>>>> shown. Is that borked?
>>>>>>>> 
>>>>>>>> Lars
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Todd Lipcon
>>>> Software Engineer, Cloudera
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Todd Lipcon
> Software Engineer, Cloudera

Mime
View raw message