Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # user - Looking for a single row - HTable.get(Get) or Scan(Get)


Copy link to this message
-
Re: Looking for a single row - HTable.get(Get) or Scan(Get)
Bryan Beaudreault 2012-05-10, 14:04
I was under the impression that a single-row Scan can use the bloom filter
as well.  Can anyone verify/refute?

On Thu, May 10, 2012 at 5:31 AM, Igal Shilman <[EMAIL PROTECTED]> wrote:

> I think that it is also worth mentioning, that Gets can be much more I/O
> efficient then Scans if you have bloom filters enabled.
>
> On Thu, May 10, 2012 at 12:29 AM, Doug Meil
> <[EMAIL PROTECTED]>wrote:
>
> >
> > Also, there is multi-Get support as of 0.90.x to further optimize the RPC
> > calls if you need to make a bunch of calls.
> >
> >
> >
> >
> >
> > On 5/9/12 4:47 PM, "Jean-Daniel Cryans" <[EMAIL PROTECTED]> wrote:
> >
> > >What Bryan said, also Scan(Get) is used internally in the region
> > >server code so that's probably why that constructor exists.
> > >
> > >But as a user you need to create the scanner, do next() then close it
> > >so using a straight Get saves 2 rpc.
> > >
> > >J-D
> > >
> > >On Wed, May 9, 2012 at 1:43 PM, Bryan Beaudreault
> > ><[EMAIL PROTECTED]> wrote:
> > >> Gets just boil down to single-row Scans.  I believe the only reason to
> > >>do
> > >> Scan s = new Scan(Get) would be if you need to add extra options onto
> > >>the
> > >> get.  Get's API is more simplified than Scan's.
> > >>
> > >> On Wed, May 9, 2012 at 4:19 PM, Kevin <[EMAIL PROTECTED]>
> > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> From what I can tell, there are two ways of scanning a table in
> HBase.
> > >>>I'm
> > >>> hoping to learn a bit by asking is the most efficient way to grab a
> > >>>single
> > >>> row from an HTable?
> > >>>
> > >>> One can ask the HTable directly by creating a Get object, or one can
> > >>>create
> > >>> a Scan object with a Get object and pass it along to the HTable.
> > >>>
> > >>> Maybe it doesn't matter. By looking at the source code I couldn't see
> > >>>how
> > >>> any one way might be faster/better than another.
> > >>>
> > >>> Thanks.
> > >>>
> > >
> >
> >
> >
>