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

Switch to Threaded View
HBase >> mail # user >> [HBase] dummy cached location when batch insert result in bad performances.


Copy link to this message
-
Re: [HBase] dummy cached location when batch insert result in bad performances.
Samuel:
Please also tell us the version of HBase you're using.

Region location caching is an active area of development. In 0.95 and
beyond, RegionMovedException is introduced so that location caching is
smarter.

Cheers

On Mon, Mar 4, 2013 at 8:28 AM, Anoop John <[EMAIL PROTECTED]> wrote:

> The guide explains it well..  The region moves across RSs and splits of
> region will cause the location cache(at client) to be stale and it will
> look into META again.  The memory flush/compaction and all will not make it
> to happen. When there is a change for the META entry for a region, the
> location cache can become stale.   Can you check the logs at RS side and
> Master side?  Lot of region movements happening?  Or may be lot of splits?
> You table is presplit ?
>
> -Anoop-
>
> On Mon, Mar 4, 2013 at 4:04 PM, <[EMAIL PROTECTED]> wrote:
>
> >
> > Dear experts,
> >
> > We met a performance issue when batch insert HBase that our client met
> > several "cached location" randomly during batch insert. We would like to
> > know when will hbase client trigger cached location again, is it related
> to
> > region split. merged or move or related to memory flush or other event?
> Are
> > there any better configuration to enhance the cached location performance
> > if it's a necessary behavior inside hbase? Thanks
> >
> >
> > In HBase-The definitive guide, page#346, it wrote:
> > Although clients cache region locations, there is an initial need to
> figure
> > out where to
> > send requests when looking for a specific row key—or when the cache is
> > stale and a
> > region has since been split, merged, or moved. The client library uses a
> > recursive discovery
> > process moving up in the hierarchy to find the current information. It
> asks
> > the
> > corresponding region server hosting the matching .META. region for the
> > given row key
> > and retrieves the address. If that information is invalid, it backs out,
> > asking the root
> > table where the .META. region is. Eventually, if all else fails, it has
> to
> > do a read of the
> > ZooKeeper node to find the root table region.
> >
> >
> > Best Regards.
> > Sam
> >
> >
> >
>  ---------------------------------------------------------------------------
> >                                                          TSMC PROPERTY
> >  This email communication (and any attachments) is proprietary
> information
> >  for the sole use of its
> >  intended recipient. Any unauthorized review, use or distribution by
> anyone
> >  other than the intended
> >  recipient is strictly prohibited.  If you are not the intended
> recipient,
> >  please notify the sender by
> >  replying to this email, and then delete this email and any copies of it
> >  immediately. Thank you.
> >
> >
>  ---------------------------------------------------------------------------
> >
> >
> >
> >
> >
>