For PageFilter :

 * Implementation of Filter interface that limits results to a specific page

 * size. It terminates scanning once the number of filter-passed rows is >

 * the given page size.

In your case, what should be the page size - 0 ?

Cheers

On Tue, May 19, 2015 at 8:30 PM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:

> Oh, I see! So basically we do a full table scan because it never returns a
> 2nd row, so we never reach that break and we exit only when we reach the
> end of the table. Therefore the same performances without the limit
> parameter...
>
> Should we then try to add a filter like PageFilter to the scan if we have a
> LIMIT? At least that might avoid a full scan?
>
> 2015-05-19 23:14 GMT-04:00 Matteo Bertozzi <theo.berto...@gmail.com>:
>
> > Take a look at table.rb _scan_internal()
> > LIMIT is not passed to the server, so you fetch more rows
> >
> >
> https://github.com/apache/hbase/blob/master/hbase-shell/src/main/ruby/hbase/table.rb#L495
> >
> > Matteo
> >
> >
> > On Tue, May 19, 2015 at 8:11 PM, Jean-Marc Spaggiari <
> > jean-m...@spaggiari.org> wrote:
> >
> > > I tried to run scan/get/scan/get many times, and always the same
> pattern.
> > > You can remove the "LIMIT => 1" parameter and you will get the same
> > > performances.
> > >
> > > Scan and get without the QC returns in very similar time. 191ms for
> one,
> > > 194ms for the other one.
> > >
> > > 2015-05-19 23:02 GMT-04:00 Ted Yu <yuzhih...@gmail.com>:
> > >
> > > > J-M:
> > > > How many times did you try the pair of queries ?
> > > >
> > > > Since scan was run first, this would give the get query some
> advantage,
> > > > right ?
> > > >
> > > > Cheers
> > > >
> > > > On Tue, May 19, 2015 at 7:34 PM, Jean-Marc Spaggiari <
> > > > jean-m...@spaggiari.org> wrote:
> > > >
> > > > > Are not Scan and Gets supposed to be almost as fast?
> > > > >
> > > > > I have a pretty small table with 65K lines, few columns (hundred?)
> > > trying
> > > > > to go a get and a scan.
> > > > >
> > > > > hbase(main):009:0> scan 'sensors', { COLUMNS =>
> > > > > ['v:f92acb5b-079a-42bc-913a-657f270a3dc1'], STARTROW => '000a',
> LIMIT
> > > =>
> > > > 1
> > > > > }
> > > > > ROW
> > > > > COLUMN+CELL
> > > > >
> > > > >  000a
> > > > > column=v:f92acb5b-079a-42bc-913a-657f270a3dc1,
> > timestamp=1432088038576,
> > > > >
> > > >
> > >
> >
> value=\x08000aHf92acb5b-079a-42bc-913a-657f270a3dc1\x0EFAILURE\x0CNE-858\x
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> 140-0000-000\x02\x96\x01SXOAXTPSIUFPPNUCIEVQGCIZHCEJBKGWINHKIHFRHWHNATAHAHQBFRAYLOAMQEGKLNZIFM
> > > > > 000a
> > > > > 1 row(s) in 12.6720 seconds
> > > > >
> > > > > hbase(main):010:0> get 'sensors', '000a', {COLUMN =>
> > > > > 'v:f92acb5b-079a-42bc-913a-657f270a3dc1'}
> > > > > COLUMN
> > > > > CELL
> > > > >
> > > > >  v:f92acb5b-079a-42bc-913a-657f270a3dc1
> > > > timestamp=1432088038576,
> > > > >
> > > > >
> > > >
> > >
> >
> value=\x08000aHf92acb5b-079a-42bc-913a-657f270a3dc1\x0EFAILURE\x0CNE-858\x140-0000-000\x02\x96\x01SXOAXTPSIUFPPNUCIEVQGCI
> > > > >
> > > > > ZHCEJBKGWINHKIHFRHWHNATAHAHQBFRAYLOAMQEGKLNZIFM
> > > > > 000a
> > > > >
> > > > > 1 row(s) in 0.0280 seconds
> > > > >
> > > > >
> > > > > They both return the same result. However, the get returns in 28ms
> > > while
> > > > > the scan returns in 12672ms.
> > > > >
> > > > > How come can the scan be that slow? Is it normal? If I remove the
> QC
> > > from
> > > > > the scan, then it takes only 250ms to return all the columns. I
> think
> > > > > something is not correct.
> > > > >
> > > > > I'm running on 1.0.0-cdh5.4.0 so I guess it's the same for 1.0.x...
> > > > >
> > > > > JM
> > > > >
> > > >
> > >
> >
>

Reply via email to