[
https://issues.apache.org/jira/browse/HBASE-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703513#action_12703513
]
Erik Holstad commented on HBASE-1249:
-------------------------------------
+ Do you mean TimeRange, or are you really talking about TimeStamp?
+ Versions are handled differently depending on what kind of query is is, but
basically there is a separate list that keeps track of how many versions that
have been fetched that lines up with the list of KeyValue fetched.
+ The Family object is not needed but it makes a nice abstraction from the
array of arrays, and for the case of using the family for e get, you don't need
to store the family name more than once, which is not the case with the old
way. I nice thing with having a family object is also that you don't need to
look at the objects themselves to figure out what family it is, since it is
stored separately.
+ The GetXServer is a GetX that has be deserialized on the server, but also
includes the compareTo(KeyValue) method and some other get specific methods
that belong on the server side. Yes the compareTo(KeyValue) method in the
GetXServer class checks everything from row/column to ttl, TimeRange, Filter
and versions, everything is handled in this method. The reason that there are
to different return code for next storefile and Done is to be able to early
out, so that you don't have to go to the next storfile, but you are right, it
should probably be called something else than compareTo since it doesn't have
the expected return codes.
+So in the GetXServer class you have like 6 different list, you have gets,
newGets, deletes, newDeletes, versions and newVersions, all of these are not
used for all types of gets but basically how it works it that you create the
newList in the current storefile and after every store file you merge the 2
lists into one and they are but into the non new lists.
+All the compare code that I'm using is currently in the GetXServer class, the
only external compare that I'm currently using it Bytes.compare(). The reason
that I've done it this way is because I don't want to recalculate the offsets
and lengths when doing different compares. I don't have a deleteSet just a list
of KeyValues that are deletes. The basic layout that we can't escape is that we
have 3 lists, one with the KeyValues in the current memcache/storefile, data,
one with things that we are looking for, gets and one with the deletes. So
instead of having sets or sortedmaps where these are stores we just have 3
sorted lists. So for every data, we look in the get list to see if that entry
can be found and iterate down the get list until we find that entry or
something that is bigger. In the case of a hit in the get list we do the same
thing in the delete list. This means that if the lists are k, l, m long worst
case lookup are k+l+m.
+ I haven't done anything with filters yet, I just have a part in the
compareTo(KeyValue) where the filter check should sit.
> Rearchitecting of server, client, API, key format, etc for 0.20
> ---------------------------------------------------------------
>
> Key: HBASE-1249
> URL: https://issues.apache.org/jira/browse/HBASE-1249
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: Jonathan Gray
> Priority: Blocker
> Fix For: 0.20.0
>
> Attachments: HBASE-1249-Example-v1.pdf, HBASE-1249-Example-v2.pdf,
> HBASE-1249-GetQuery-v1.pdf, HBASE-1249-GetQuery-v2.pdf,
> HBASE-1249-GetQuery-v3.pdf, HBASE-1249-GetQuery-v4.pdf,
> HBASE-1249-StoreFile-v1.pdf, HBASE-1249-StoreFile-v4.pdf
>
>
> To discuss all the new and potential issues coming out of the change in key
> format (HBASE-1234): zero-copy reads, client binary protocol, update of API
> (HBASE-880), server optimizations, etc...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
