Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Understanding scan behaviour


Copy link to this message
-
Re: Understanding scan behaviour
Thanks, that's a good point about last byte being max :)

When I query 1234555..1234556 do I also get row for 1234556 if one exist?

On Sat, Mar 30, 2013 at 6:55 AM, Asaf Mesika <[EMAIL PROTECTED]> wrote:

> Yes.
> Watch out for last byte being max
>
>
> On Fri, Mar 29, 2013 at 7:31 PM, Mohit Anchlia <[EMAIL PROTECTED]
> >wrote:
>
> > Thanks everyone, it's really helpful. I'll change my prefix filter to end
> > row. Is it necessary to increment the last byte? So if I have hash of
> > 1234555 my end key should be 1234556?
> >
> >
> > On Thu, Mar 28, 2013 at 11:20 PM, ramkrishna vasudevan <
> > [EMAIL PROTECTED]> wrote:
> >
> > > Mohith,
> > >
> > > It is always better to go with start row and end row if you are knowing
> > > what are they.
> > > Just add one byte more to the actual end row (inclusive row) and form
> the
> > > end key.  This will narrow down the search.
> > >
> > > Remeber the byte comparison is the way that HBase scans.
> > > Regards
> > > Ram
> > >
> > > On Fri, Mar 29, 2013 at 11:18 AM, Li, Min <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Hi, Mohit,
> > > >
> > > > Try using ENDROW. STARTROW&ENDROW is much faster than PrefixFilter.
> > > >
> > > > "+" ascii code is 43
> > > > "," ascii code is 44
> > > >
> > > > scan 'SESSIONID_TIMELINE', {LIMIT => 1,STARTROW => '++++',
> > > ENDROW=>'+++,'}
> > > >
> > > > Min
> > > >
> > > > -----Original Message-----
> > > > From: Mohit Anchlia [mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, March 29, 2013 1:18 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: Understanding scan behaviour
> > > >
> > > > Could the prefix filter lead to full tablescan? In other words is
> > > > PrefixFilter applied after fetching the rows?
> > > >
> > > > Another question I have is say I have row key abc and abd and I
> search
> > > for
> > > > row "abc", is it always guranteed to be the first key when returned
> > from
> > > > scanned results? If so I can alway put a condition in the client app.
> > > >
> > > > On Thu, Mar 28, 2013 at 9:15 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Take a look at the following in
> > > > > hbase-server/src/main/ruby/shell/commands/scan.rb
> > > > > (trunk)
> > > > >
> > > > >   hbase> scan 't1', {FILTER => "(PrefixFilter ('row2') AND
> > > > >     (QualifierFilter (>=, 'binary:xyz'))) AND (TimestampsFilter (
> > 123,
> > > > > 456))"}
> > > > >
> > > > > Cheers
> > > > >
> > > > > On Thu, Mar 28, 2013 at 9:02 AM, Mohit Anchlia <
> > [EMAIL PROTECTED]
> > > > > >wrote:
> > > > >
> > > > > > I see then I misunderstood the behaviour. My keys are id +
> > timestamp
> > > so
> > > > > > that I can do a range type search. So what I really want is to
> > > return a
> > > > > row
> > > > > > where id matches the prefix. Is there a way to do this without
> > having
> > > > to
> > > > > > scan large amounts of data?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Mar 28, 2013 at 8:26 AM, Jean-Marc Spaggiari <
> > > > > > [EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > > Hi Mohit,
> > > > > > >
> > > > > > > "+" ascii code is 43
> > > > > > > "9" ascii code is 57.
> > > > > > >
> > > > > > > So "+9" is coming after "++". If you don't have any row with
> the
> > > > exact
> > > > > > > key "+++++", HBase will look for the first one after this one.
> > And
> > > in
> > > > > > > your case, it's
> > > +9hC\xFC\x82s\xABL3\xB3B\xC0\xF9\x87\x03\x7F\xFF\xF.
> > > > > > >
> > > > > > > JM
> > > > > > >
> > > > > > > 2013/3/28 Mohit Anchlia <[EMAIL PROTECTED]>:
> > > > > > > > My understanding is that the row key would start with +++++
> for
> > > > > > instance.
> > > > > > > >
> > > > > > > > On Thu, Mar 28, 2013 at 7:53 AM, Jean-Marc Spaggiari <
> > > > > > > > [EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > >> Hi Mohit,
> > > > > > > >>
> > > > > > > >> I see nothing wrong with the results below. What would I
> have
> > > > > > expected?
> > > > > > > >>
> > > > > > > >> JM
> > > > > > > >>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB