The custom split policy needs to respect the fact that timestamp is the leading part of the rowkey.
This would avoid the overlap you mentioned. Cheers > On May 21, 2015, at 11:55 PM, Shushant Arora <shushantaror...@gmail.com> > wrote: > > guid change with every key, patterns is > 2015-05-22 00:02:01#AB12EC77778888945 > 2015-05-22 00:02:02#CD9870001234AB457 > > When we specify custom split algorithm , it may happen that keys of same > sorting order range say (1-7) lies in region R1 as well as in region R2? > Then how .META. table will make further lookups at read time, say I search > for key 3, then will it search in both the regions R1 and R2 ? > >> On Fri, May 22, 2015 at 10:48 AM, Ted Yu <yuzhih...@gmail.com> wrote: >> >> Does guid change with every key ? >> >> bq. use second part of key >> >> I don't think so. Suppose first row in the parent region is >> '1432104178817#321'. After split, the first row in first daughter region >> would still be '1432104178817#321'. Right ? >> >> Cheers >> >> On Thu, May 21, 2015 at 9:57 PM, Shushant Arora <shushantaror...@gmail.com >> wrote: >> >>> Can I avoid hotspot of region with custom region split policy in hbase >>>> 0.96 . >>> >>> Key is of the form timestamp#guid. >>> So can I have custom region split policy and use second part of key (i.e) >>> guid as region split criteria and avoid hot spot?? >>
