[
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:
--------------------------------------
{quote}
Below is odd especially when Get does not implement Map
{quote}
Get.entrySet() now replaced with Get.getFamilyMap()
{quote}
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?
{quote}
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 format.
{quote}
What's this? (Result.rowResult())
{quote}
Will return existing RowResult. Commented out because I've not integrated all
the code into this patch yet.
{quote}
Lots of common code. Common base abstract class?
{quote}
Which class(es) are you referring to?
{quote}
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?
{quote}
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.
