hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Meil <doug.m...@explorysmedical.com>
Subject rowlock advice for book
Date Wed, 11 Jan 2012 21:08:28 GMT

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" <stack@duboce.net> wrote:

>On Tue, Jan 3, 2012 at 12:38 PM, Joe Stein
><charmalloc@allthingshadoop.com> wrote:
>> when the event happened so if we see something from November 3rd today
>> 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
>> and when we set the timestamp in our checkAndPut we make the timestamp
>> 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
>> 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
>> re-TTL trillions of rows =8^( (which is nagging thought in the back of
>> 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
>> to Cassandra and do lots of wide column range slices on those columns
>> is like inverting everything up on myself but the row locks and
>> (and co-processors) hit so many of my uses cases (as Cassandra still
>> 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
>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
>> 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
>> 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

View raw message