On Wed, Jan 11, 2012 at 3:39 PM, lars hofhansl <lhofha...@yahoo.com> wrote: > Shouldn't we deprecate them? >
Yes. But what to replace them with? I think they haven't been deprecated up to this because we've not done the work to put in place an alternative. We could just drop the functionality (after deprecating). I'd be fine w/ that. St.Ack > They are only guaranteed to work for the duration of a region server > operation. > If there are splits/etc the lock would be silently gone. > > -- Lars > > > > ________________________________ > From: Jean-Daniel Cryans <jdcry...@apache.org> > To: dev@hbase.apache.org > Sent: Wednesday, January 11, 2012 2:36 PM > Subject: Re: rowlock advice for book > > Row locks aren't deprecated officially but it's really that type of > feature that you should use at your own risk / you might not enjoy > life after that. > > J-D > > On Wed, Jan 11, 2012 at 1:08 PM, Doug Meil > <doug.m...@explorysmedical.com> wrote: >> >> Hey dev-list, regarding this... >> >> re: "Be careful using hbase row locks. They are (unofficially -- we need >> to make it official) deprecated." >> >> >> >> >> ... is this the official advice? Should I update the book with this? >> >> >> >> >> On 1/3/12 4:37 PM, "Stack" <st...@duboce.net> wrote: >> >>>On Tue, Jan 3, 2012 at 12:38 PM, Joe Stein >>><charmal...@allthingshadoop.com> wrote: >>>> when the event happened so if we see something from November 3rd today >>>>then >>>> we will only keep it for 4 more months (and for events that we see today >>>> those stay for 6 months) . so it sounds like this might be a viable >>>>option >>>> and when we set the timestamp in our checkAndPut we make the timestamp >>>>be >>>> the value that represents it as November 3rd, right? cool >>>> >>> >>>This should be fine. >>> >>>You might want to protect against future dates. >>> >>>> well what i was thinking is that my client code would know to use the >>>> november table and put the data in the november table (it is all just >>>> strings) but I am leaning now towards the TTL option (need to futz with >>>>it >>>> all more though). One issue/concern with TTL is when all of a sudden we >>>> want to keep things for only 4 months or maybe 8 months and then having >>>>to >>>> re-TTL trillions of rows =8^( (which is nagging thought in the back of >>>>my >>>> head about ttls, requirements change).... >>> >>>This schema attribute is kept at the table level, not per row. You'll >>>have to change the table schema which in 0.90.x hbase means offlining >>>table (in 0.92 hbase, there is an online schema edit but needs to be >>>enabled and can be problematic in the face of splitting.... more on >>>this later). >>> >>>> That makes sense why a narrow long schema works well then, got it (I am >>>>use >>>> to Cassandra and do lots of wide column range slices on those columns >>>>this >>>> is like inverting everything up on myself but the row locks and >>>>checkAndPut >>>> (and co-processors) hit so many of my uses cases (as Cassandra still >>>>does >>>> also) >>>> >>> >>>Be careful using hbase row locks. They are (unofficially -- we need >>>to make it official) deprecated. You can lock yourself out of a >>>regionserver if all incoming handlers end up waiting on a particular >>>row lock to clear. Check back in this mailing list for other rowlock >>>downsides. >>> >>>You can column range slices in hbase if you use filters (if you need to). >>> >>>checkAndPut shouldn't care if row is wide or not? >>> >>> >>>> right now I am on 0.90.4 but right now I am going back and forth in >>>> changing our hadoop cluster, HBase is the primary driver for that so I >>>>am >>>> currently wrestling on the decision with upgrading from existing cluster >>>> CDH2 to CDH3 or going with MapR ... >>> >>>Go to CDH3 if you are on CDH2. Does CDH2 have a working sync? >>>(CDH3u3 when it arrives has some nice perf improvements). >>> >>>> my preference is to run my own version >>>> of HBase (like I do with Kafka and Cassandra) I feel I can do this >>>>though I >>>> am not comfortable with running my own Hadoop build (already overloaded >>>> with things). 0.92 is exciting for co-processors too and it is cool >>>>system >>>> to hack on, maybe I will pull from trunk build and test it out some too. >>>> >>> >>>Don't do hbase trunk. Do tip of 0.92 branch if you want to hack. >>>HBase Trunk is different from 0.92 already and will get even more >>>"differenter"; it'll be hard to help you if you are pulling from trunk >>> >>>St.Ack >>> >> >>
