since custom split policy is based on second part i.e guid so key with first part as 2015-05-22 00:01:02 will be in which region how will that be identified?
On Fri, May 22, 2015 at 1:12 PM, Ted Yu <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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 < > [email protected] > >> 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?? > >> >
