You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by S L <sl...@gmail.com> on 2017/07/15 02:51:09 UTC

How does hbase find regionservers for scans

Sorry if this is a basic question.  How does hbase determine which
regionserver the rows are supposed to be stored on?  My rowkey looks like
hash_servername_timestamp, e.g.

33_myserver.mydomain.com_1234567890

If I run the following command:

scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}

I get all the rows that start with "0".  Since hbase stores things in
lexical order, it seems like all rows that were stored lexically first gets
returned.

However, if I run the following command, hbase times out.  Even if I extend
the timeout period to 3 minutes, it still times out.

scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}

It seems like if it was any other prefix other than "0", it times out (like
above prefix = 28).  I don't understand why it would timeout since it
should be able to calculate which region/regionserver it should go to since
I gave it the prefix to use.


I performed "hbase hbck" and it says that

9 region servers are alive, 2 are dead

# of total regions is 15850 for the db but there's only 350 for the table
I'm querying.  There are 0 inconsistencies so the status is "OK".

Thanks in advance for any help you can give me.

Re: How does hbase find regionservers for scans

Posted by S L <sl...@gmail.com>.
Ted,

Yeah, it doesn't work for me.  It timesout.  Using your
rowprefixFilter works so I'll just use that and ask questions later.
Thanks again.

scan 'dbi_based_data', {FILTER => "PrefixFilter('18')"}

ROW                                COLUMN+CELL


ERROR: Call id=6, waitTime=60001, operationTimeout=60000 expired.

On Tue, Jul 18, 2017 at 12:11 PM, Ted Yu <yu...@gmail.com> wrote:
> For #1, the timestamp currently is stored using epoch in milliseconds on
> server side.
>
> For #2, PrefixFilter should also work.
> I peformed the following on a small table:
>
> scan 't', {FILTER => "PrefixFilter('111')"}
>
> which returned the two.
>
> Cheers
>
> On Tue, Jul 18, 2017 at 11:36 AM, S L <sl...@gmail.com> wrote:
>
>> Thanks for the tip with RowPrefixFilter.  THAT works compared to
>> PrefixFilter.  However, regarding the timerange, when i type in the
>> epoch time, that returns 0 rows.  However, if I use epoch time in
>> milliseconds, that returns tons of rows.
>>
>> I have more questions now:
>> 1) Why does my hbase work wtih epoch in milliseconds but your example
>> says to use epoch seconds.
>> 2) Also, how do you use PrefixFilter because I thought PrefixFilter
>> was what I needed via common sense but apparently my common sense
>> didn't work.
>>
>> Thanks for answering all my questions the last couple weeks.
>>
>>  scan 'dbi_based_data', {ROWPREFIXFILTER=> '26', COLUMNS =>
>> 'raw_data:processlist', TIMERANGE => [1499205600, 1499206200]}
>>
>> ROW                                COLUMN+CELL
>>
>> 0 row(s) in 0.2350 seconds
>>
>>
>> scan 'dbi_based_data', {ROWPREFIXFILTER=> '26', COLUMNS =>
>> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>>
>> <snip snip>
>> <snpi snip>
>>
>> 26_p3419.db160151.ycg1.dbi_149920 column=raw_data:processlist,
>> timestamp=1499206083343, value= <snip snip>
>>
>> 351 row(s) in 184.6360 seconds
>>
>>
>>
>>
>> On Fri, Jul 14, 2017 at 8:14 PM, Ted Yu <yu...@gmail.com> wrote:
>> >
>> > I wonder what time unit you were using.
>> >
>> > From the example in hbase-shell/src/main/ruby/shell/commands/scan.rb :
>> >
>> >   hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804,
>> 1303668904]}
>> >
>> > You can see the time range having much smaller values.
>> >
>> > Please look at ROWPREFIXFILTER example in the same scan.rb
>> >
>> > If you check the table UI for dbi_based_data, you would see the start key
>> > of each region.
>> > From there it is easy to pinpoint which server hosts the relevant region.
>> >
>> > Cheers
>> >
>> > On Fri, Jul 14, 2017 at 7:51 PM, S L <sl...@gmail.com> wrote:
>> >
>> > > Sorry if this is a basic question.  How does hbase determine which
>> > > regionserver the rows are supposed to be stored on?  My rowkey looks
>> like
>> > > hash_servername_timestamp, e.g.
>> > >
>> > > 33_myserver.mydomain.com_1234567890
>> > >
>> > > If I run the following command:
>> > >
>> > > scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
>> > > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>> > >
>> > > I get all the rows that start with "0".  Since hbase stores things in
>> > > lexical order, it seems like all rows that were stored lexically first
>> gets
>> > > returned.
>> > >
>> > > However, if I run the following command, hbase times out.  Even if I
>> extend
>> > > the timeout period to 3 minutes, it still times out.
>> > >
>> > > scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
>> > > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>> > >
>> > > It seems like if it was any other prefix other than "0", it times out
>> (like
>> > > above prefix = 28).  I don't understand why it would timeout since it
>> > > should be able to calculate which region/regionserver it should go to
>> since
>> > > I gave it the prefix to use.
>> > >
>> > >
>> > > I performed "hbase hbck" and it says that
>> > >
>> > > 9 region servers are alive, 2 are dead
>> > >
>> > > # of total regions is 15850 for the db but there's only 350 for the
>> table
>> > > I'm querying.  There are 0 inconsistencies so the status is "OK".
>> > >
>> > > Thanks in advance for any help you can give me.
>> > >
>>

Re: How does hbase find regionservers for scans

Posted by Ted Yu <yu...@gmail.com>.
For #1, the timestamp currently is stored using epoch in milliseconds on
server side.

For #2, PrefixFilter should also work.
I peformed the following on a small table:

scan 't', {FILTER => "PrefixFilter('111')"}

which returned the two.

Cheers

On Tue, Jul 18, 2017 at 11:36 AM, S L <sl...@gmail.com> wrote:

> Thanks for the tip with RowPrefixFilter.  THAT works compared to
> PrefixFilter.  However, regarding the timerange, when i type in the
> epoch time, that returns 0 rows.  However, if I use epoch time in
> milliseconds, that returns tons of rows.
>
> I have more questions now:
> 1) Why does my hbase work wtih epoch in milliseconds but your example
> says to use epoch seconds.
> 2) Also, how do you use PrefixFilter because I thought PrefixFilter
> was what I needed via common sense but apparently my common sense
> didn't work.
>
> Thanks for answering all my questions the last couple weeks.
>
>  scan 'dbi_based_data', {ROWPREFIXFILTER=> '26', COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600, 1499206200]}
>
> ROW                                COLUMN+CELL
>
> 0 row(s) in 0.2350 seconds
>
>
> scan 'dbi_based_data', {ROWPREFIXFILTER=> '26', COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>
> <snip snip>
> <snpi snip>
>
> 26_p3419.db160151.ycg1.dbi_149920 column=raw_data:processlist,
> timestamp=1499206083343, value= <snip snip>
>
> 351 row(s) in 184.6360 seconds
>
>
>
>
> On Fri, Jul 14, 2017 at 8:14 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> > I wonder what time unit you were using.
> >
> > From the example in hbase-shell/src/main/ruby/shell/commands/scan.rb :
> >
> >   hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804,
> 1303668904]}
> >
> > You can see the time range having much smaller values.
> >
> > Please look at ROWPREFIXFILTER example in the same scan.rb
> >
> > If you check the table UI for dbi_based_data, you would see the start key
> > of each region.
> > From there it is easy to pinpoint which server hosts the relevant region.
> >
> > Cheers
> >
> > On Fri, Jul 14, 2017 at 7:51 PM, S L <sl...@gmail.com> wrote:
> >
> > > Sorry if this is a basic question.  How does hbase determine which
> > > regionserver the rows are supposed to be stored on?  My rowkey looks
> like
> > > hash_servername_timestamp, e.g.
> > >
> > > 33_myserver.mydomain.com_1234567890
> > >
> > > If I run the following command:
> > >
> > > scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
> > > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> > >
> > > I get all the rows that start with "0".  Since hbase stores things in
> > > lexical order, it seems like all rows that were stored lexically first
> gets
> > > returned.
> > >
> > > However, if I run the following command, hbase times out.  Even if I
> extend
> > > the timeout period to 3 minutes, it still times out.
> > >
> > > scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
> > > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> > >
> > > It seems like if it was any other prefix other than "0", it times out
> (like
> > > above prefix = 28).  I don't understand why it would timeout since it
> > > should be able to calculate which region/regionserver it should go to
> since
> > > I gave it the prefix to use.
> > >
> > >
> > > I performed "hbase hbck" and it says that
> > >
> > > 9 region servers are alive, 2 are dead
> > >
> > > # of total regions is 15850 for the db but there's only 350 for the
> table
> > > I'm querying.  There are 0 inconsistencies so the status is "OK".
> > >
> > > Thanks in advance for any help you can give me.
> > >
>

Re: How does hbase find regionservers for scans

Posted by S L <sl...@gmail.com>.
Thanks for the tip with RowPrefixFilter.  THAT works compared to
PrefixFilter.  However, regarding the timerange, when i type in the
epoch time, that returns 0 rows.  However, if I use epoch time in
milliseconds, that returns tons of rows.

I have more questions now:
1) Why does my hbase work wtih epoch in milliseconds but your example
says to use epoch seconds.
2) Also, how do you use PrefixFilter because I thought PrefixFilter
was what I needed via common sense but apparently my common sense
didn't work.

Thanks for answering all my questions the last couple weeks.

 scan 'dbi_based_data', {ROWPREFIXFILTER=> '26', COLUMNS =>
'raw_data:processlist', TIMERANGE => [1499205600, 1499206200]}

ROW                                COLUMN+CELL

0 row(s) in 0.2350 seconds


scan 'dbi_based_data', {ROWPREFIXFILTER=> '26', COLUMNS =>
'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}

<snip snip>
<snpi snip>

26_p3419.db160151.ycg1.dbi_149920 column=raw_data:processlist,
timestamp=1499206083343, value= <snip snip>

351 row(s) in 184.6360 seconds




On Fri, Jul 14, 2017 at 8:14 PM, Ted Yu <yu...@gmail.com> wrote:
>
> I wonder what time unit you were using.
>
> From the example in hbase-shell/src/main/ruby/shell/commands/scan.rb :
>
>   hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804, 1303668904]}
>
> You can see the time range having much smaller values.
>
> Please look at ROWPREFIXFILTER example in the same scan.rb
>
> If you check the table UI for dbi_based_data, you would see the start key
> of each region.
> From there it is easy to pinpoint which server hosts the relevant region.
>
> Cheers
>
> On Fri, Jul 14, 2017 at 7:51 PM, S L <sl...@gmail.com> wrote:
>
> > Sorry if this is a basic question.  How does hbase determine which
> > regionserver the rows are supposed to be stored on?  My rowkey looks like
> > hash_servername_timestamp, e.g.
> >
> > 33_myserver.mydomain.com_1234567890
> >
> > If I run the following command:
> >
> > scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
> > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> >
> > I get all the rows that start with "0".  Since hbase stores things in
> > lexical order, it seems like all rows that were stored lexically first gets
> > returned.
> >
> > However, if I run the following command, hbase times out.  Even if I extend
> > the timeout period to 3 minutes, it still times out.
> >
> > scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
> > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> >
> > It seems like if it was any other prefix other than "0", it times out (like
> > above prefix = 28).  I don't understand why it would timeout since it
> > should be able to calculate which region/regionserver it should go to since
> > I gave it the prefix to use.
> >
> >
> > I performed "hbase hbck" and it says that
> >
> > 9 region servers are alive, 2 are dead
> >
> > # of total regions is 15850 for the db but there's only 350 for the table
> > I'm querying.  There are 0 inconsistencies so the status is "OK".
> >
> > Thanks in advance for any help you can give me.
> >

Re: How does hbase find regionservers for scans

Posted by Ted Yu <yu...@gmail.com>.
Using ROWPREFIXFILTER allows the user to specify the prefix only once.
When the length of prefix is not very short, using ROWPREFIXFILTER reduces
the chance of typo.

For prefix = 28, another possibility for timeout was that there were very
few rows satisfying the criteria on the server side.

Cheers

On Sun, Jul 16, 2017 at 8:08 AM, Allan Yang <al...@apache.org> wrote:

> If you want rows start with "0", you should use
> scan 'dbi_based_data', {STARTROW=>'0', STOPROW=>'1' COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> similar if you want rows start with '28'
> scan 'dbi_based_data', {STARTROW=>'28', STOPROW=>'29' COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>
> The query you made will became a full table scan query, that is very
> inefficient.
> As for why the second query timed out, there can be many reasons. One
> possible reason is that you have too many delete markers for rows with
> prefix '28'. A major compaction will solve this case.
> But before finding out why, I think change this queries is the first thing
> need to be done.
>
>
> Best Regards
> Allan Yang
>
> 2017-07-15 11:14 GMT+08:00 Ted Yu <yu...@gmail.com>:
>
> > I wonder what time unit you were using.
> >
> > From the example in hbase-shell/src/main/ruby/shell/commands/scan.rb :
> >
> >   hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804,
> > 1303668904]}
> >
> > You can see the time range having much smaller values.
> >
> > Please look at ROWPREFIXFILTER example in the same scan.rb
> >
> > If you check the table UI for dbi_based_data, you would see the start key
> > of each region.
> > From there it is easy to pinpoint which server hosts the relevant region.
> >
> > Cheers
> >
> > On Fri, Jul 14, 2017 at 7:51 PM, S L <sl...@gmail.com> wrote:
> >
> > > Sorry if this is a basic question.  How does hbase determine which
> > > regionserver the rows are supposed to be stored on?  My rowkey looks
> like
> > > hash_servername_timestamp, e.g.
> > >
> > > 33_myserver.mydomain.com_1234567890
> > >
> > > If I run the following command:
> > >
> > > scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
> > > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> > >
> > > I get all the rows that start with "0".  Since hbase stores things in
> > > lexical order, it seems like all rows that were stored lexically first
> > gets
> > > returned.
> > >
> > > However, if I run the following command, hbase times out.  Even if I
> > extend
> > > the timeout period to 3 minutes, it still times out.
> > >
> > > scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
> > > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> > >
> > > It seems like if it was any other prefix other than "0", it times out
> > (like
> > > above prefix = 28).  I don't understand why it would timeout since it
> > > should be able to calculate which region/regionserver it should go to
> > since
> > > I gave it the prefix to use.
> > >
> > >
> > > I performed "hbase hbck" and it says that
> > >
> > > 9 region servers are alive, 2 are dead
> > >
> > > # of total regions is 15850 for the db but there's only 350 for the
> table
> > > I'm querying.  There are 0 inconsistencies so the status is "OK".
> > >
> > > Thanks in advance for any help you can give me.
> > >
> >
>

Re: How does hbase find regionservers for scans

Posted by S L <sl...@gmail.com>.
Thanks for the tips.  I'm running these queries to debug my program
but this is good to know, especially regarding compaction.  My program
seems to keep running into problems with timing out and running into
rowkeys that look like they should have been removed due to the TTL
expiring but I couldn't prove it to anyone.

On Sun, Jul 16, 2017 at 8:08 AM, Allan Yang <al...@apache.org> wrote:
> If you want rows start with "0", you should use
> scan 'dbi_based_data', {STARTROW=>'0', STOPROW=>'1' COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> similar if you want rows start with '28'
> scan 'dbi_based_data', {STARTROW=>'28', STOPROW=>'29' COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>
> The query you made will became a full table scan query, that is very
> inefficient.
> As for why the second query timed out, there can be many reasons. One
> possible reason is that you have too many delete markers for rows with
> prefix '28'. A major compaction will solve this case.
> But before finding out why, I think change this queries is the first thing
> need to be done.
>
>
> Best Regards
> Allan Yang
>
> 2017-07-15 11:14 GMT+08:00 Ted Yu <yu...@gmail.com>:
>
>> I wonder what time unit you were using.
>>
>> From the example in hbase-shell/src/main/ruby/shell/commands/scan.rb :
>>
>>   hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804,
>> 1303668904]}
>>
>> You can see the time range having much smaller values.
>>
>> Please look at ROWPREFIXFILTER example in the same scan.rb
>>
>> If you check the table UI for dbi_based_data, you would see the start key
>> of each region.
>> From there it is easy to pinpoint which server hosts the relevant region.
>>
>> Cheers
>>
>> On Fri, Jul 14, 2017 at 7:51 PM, S L <sl...@gmail.com> wrote:
>>
>> > Sorry if this is a basic question.  How does hbase determine which
>> > regionserver the rows are supposed to be stored on?  My rowkey looks like
>> > hash_servername_timestamp, e.g.
>> >
>> > 33_myserver.mydomain.com_1234567890
>> >
>> > If I run the following command:
>> >
>> > scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
>> > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>> >
>> > I get all the rows that start with "0".  Since hbase stores things in
>> > lexical order, it seems like all rows that were stored lexically first
>> gets
>> > returned.
>> >
>> > However, if I run the following command, hbase times out.  Even if I
>> extend
>> > the timeout period to 3 minutes, it still times out.
>> >
>> > scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
>> > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>> >
>> > It seems like if it was any other prefix other than "0", it times out
>> (like
>> > above prefix = 28).  I don't understand why it would timeout since it
>> > should be able to calculate which region/regionserver it should go to
>> since
>> > I gave it the prefix to use.
>> >
>> >
>> > I performed "hbase hbck" and it says that
>> >
>> > 9 region servers are alive, 2 are dead
>> >
>> > # of total regions is 15850 for the db but there's only 350 for the table
>> > I'm querying.  There are 0 inconsistencies so the status is "OK".
>> >
>> > Thanks in advance for any help you can give me.
>> >
>>

Re: How does hbase find regionservers for scans

Posted by Allan Yang <al...@apache.org>.
If you want rows start with "0", you should use
scan 'dbi_based_data', {STARTROW=>'0', STOPROW=>'1' COLUMNS =>
'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
similar if you want rows start with '28'
scan 'dbi_based_data', {STARTROW=>'28', STOPROW=>'29' COLUMNS =>
'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}

The query you made will became a full table scan query, that is very
inefficient.
As for why the second query timed out, there can be many reasons. One
possible reason is that you have too many delete markers for rows with
prefix '28'. A major compaction will solve this case.
But before finding out why, I think change this queries is the first thing
need to be done.


Best Regards
Allan Yang

2017-07-15 11:14 GMT+08:00 Ted Yu <yu...@gmail.com>:

> I wonder what time unit you were using.
>
> From the example in hbase-shell/src/main/ruby/shell/commands/scan.rb :
>
>   hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804,
> 1303668904]}
>
> You can see the time range having much smaller values.
>
> Please look at ROWPREFIXFILTER example in the same scan.rb
>
> If you check the table UI for dbi_based_data, you would see the start key
> of each region.
> From there it is easy to pinpoint which server hosts the relevant region.
>
> Cheers
>
> On Fri, Jul 14, 2017 at 7:51 PM, S L <sl...@gmail.com> wrote:
>
> > Sorry if this is a basic question.  How does hbase determine which
> > regionserver the rows are supposed to be stored on?  My rowkey looks like
> > hash_servername_timestamp, e.g.
> >
> > 33_myserver.mydomain.com_1234567890
> >
> > If I run the following command:
> >
> > scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
> > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> >
> > I get all the rows that start with "0".  Since hbase stores things in
> > lexical order, it seems like all rows that were stored lexically first
> gets
> > returned.
> >
> > However, if I run the following command, hbase times out.  Even if I
> extend
> > the timeout period to 3 minutes, it still times out.
> >
> > scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
> > 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
> >
> > It seems like if it was any other prefix other than "0", it times out
> (like
> > above prefix = 28).  I don't understand why it would timeout since it
> > should be able to calculate which region/regionserver it should go to
> since
> > I gave it the prefix to use.
> >
> >
> > I performed "hbase hbck" and it says that
> >
> > 9 region servers are alive, 2 are dead
> >
> > # of total regions is 15850 for the db but there's only 350 for the table
> > I'm querying.  There are 0 inconsistencies so the status is "OK".
> >
> > Thanks in advance for any help you can give me.
> >
>

Re: How does hbase find regionservers for scans

Posted by Ted Yu <yu...@gmail.com>.
I wonder what time unit you were using.

From the example in hbase-shell/src/main/ruby/shell/commands/scan.rb :

  hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804, 1303668904]}

You can see the time range having much smaller values.

Please look at ROWPREFIXFILTER example in the same scan.rb

If you check the table UI for dbi_based_data, you would see the start key
of each region.
From there it is easy to pinpoint which server hosts the relevant region.

Cheers

On Fri, Jul 14, 2017 at 7:51 PM, S L <sl...@gmail.com> wrote:

> Sorry if this is a basic question.  How does hbase determine which
> regionserver the rows are supposed to be stored on?  My rowkey looks like
> hash_servername_timestamp, e.g.
>
> 33_myserver.mydomain.com_1234567890
>
> If I run the following command:
>
> scan 'dbi_based_data', {FILTER => "PrefixFilter('0')", COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>
> I get all the rows that start with "0".  Since hbase stores things in
> lexical order, it seems like all rows that were stored lexically first gets
> returned.
>
> However, if I run the following command, hbase times out.  Even if I extend
> the timeout period to 3 minutes, it still times out.
>
> scan 'dbi_based_data', {FILTER => "PrefixFilter('28')", COLUMNS =>
> 'raw_data:processlist', TIMERANGE => [1499205600000, 1499206200000]}
>
> It seems like if it was any other prefix other than "0", it times out (like
> above prefix = 28).  I don't understand why it would timeout since it
> should be able to calculate which region/regionserver it should go to since
> I gave it the prefix to use.
>
>
> I performed "hbase hbck" and it says that
>
> 9 region servers are alive, 2 are dead
>
> # of total regions is 15850 for the db but there's only 350 for the table
> I'm querying.  There are 0 inconsistencies so the status is "OK".
>
> Thanks in advance for any help you can give me.
>