hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Gray (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1304) New client server implementation of how gets and puts are handled.
Date Sat, 09 May 2009 00:28:45 GMT

    [ https://issues.apache.org/jira/browse/HBASE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707577#action_12707577

Jonathan Gray commented on HBASE-1304:

Below is odd especially when Get does not implement Map
Get.entrySet() now replaced with Get.getFamilyMap()

Seems a pity creating a TreeMap when usual case is single family. Later we can optimize and
only create the TreeMap on addition of second family?
Yeah, there a number of additional optimizations that can be made all over the place.  Will
be good to see profiling, so my focus is on major algorithmic improvements first and then
we can dig in further if need be.  Depending how things go, we can get additional server-side
optimizations by having separate client-side/server-side Get/Put/etc that share a common Writable

What's this? (Result.rowResult())
Will return existing RowResult.  Commented out because I've not integrated all the code into
this patch yet.

Lots of common code. Common base abstract class?
Which class(es) are you referring to?

Regards TimeRange, are we for sure that most compares of timestamps are byte [] rather than
long? This class is written for byte []. Surely compare of two longs is faster than creation
of byte array representation and then byte compare?
Erik liked the idea of storing byte[]'s, but that's what we could be comparing to.  While
writing the code, I found it so much easier to deal with longs.  There is a difference between
comparing byte[]'s vs converting a byte[] to a long and comparing longs directly, but again
it's orders of magnitude less significant than other changes (as you suggest), so I'd rather
keep it simple.  I'm thinking of changing TimeRange to just storing the longs.  We can change
to byte[] later if shown to make a measurable difference.

Regarding Result being constructed server-side... I agree we should save wherever possible,
but in this case I think a single object instantiation per query is tolerable to keep things
easier to work with.  Result is where our custom Writable implementation lives, which leaves
the door open for further optimizations (reading all KeyValues into one big byte[] rather
than single byte[] allocation per KV).  We also might have other things to attach to it in
the future.  That being said, it's about three lines of code to change this and I don't feel
that strongly either way.

+1 on all other formatting/spacing/refactor changes, will do.

Thanks a bunch for the review stack.  Keep it coming.

> New client server implementation of how gets and puts are handled. 
> -------------------------------------------------------------------
>                 Key: HBASE-1304
>                 URL: https://issues.apache.org/jira/browse/HBASE-1304
>             Project: Hadoop HBase
>          Issue Type: Improvement
>    Affects Versions: 0.20.0
>            Reporter: Erik Holstad
>            Assignee: Jonathan Gray
>            Priority: Blocker
>             Fix For: 0.20.0
>         Attachments: hbase-1304-v1.patch, HBASE-1304-v2.patch, HBASE-1304-v3.patch
> Creating an issue where the implementation of the new client and server will go. Leaving
HBASE-1249 as a discussion forum and will put code and patches here.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message