hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1249) Rearchitecting of server, client, API, key format, etc for 0.20
Date Tue, 28 Apr 2009 17:29:30 GMT

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

stack commented on HBASE-1249:


+ If client-side needs to reflect server-implementation, then we're off going by current state
of src (Server objective is all byte arrays, client is introducing classes that are carried
over to the server and then made into byte arrays; e.g. Family).
+ I'm against two implementations, a 'slimmer' byte-based, and then a object-based one for
more complex queries IF they do not resolve to same thing client side (otherwise, as I see
it we are multiplying the number of client/server methods and reasoning in server)
+ Family:column has been reined in server-side with comparators that compare the family only
portion of column -- no new allocations.
+ I'm grand w/ lots of objects client-side but not wanton profligacy -- should be elegant
+ I wish I saw more KV in the current src; seems little going between client and server currently.
+ If we've gone past the current store file, and we have enough versions... thats how we figure
when we can early-out, right?  What other factor is there?  Only one that might complicate
is the GetTop.  For that, you need to count versions differently -- not per column-family
but in total -- IIUC.  Has to be really good reason for doing a compare that is like but just
a little different from what devs are used to.
+ I wonder why bother with NewDeletes?  Just add them to the running deletes list?  Its a
lookup into a sorted set so extra numbers will make a very-slight difference, not enough of
a difference that its worth instantiating 3x the lists and running combine as we move from
one storefile to the next I'd guess (Looks like I'm not getting something here in the way
the test if a cell is deleted is working -- please help me understand if I'm missing something
about how this system works.. the delete system).
+ OK w/ putting of filters to 0.21... using what we have not if we can.


+ Version handling inside the compareTo says to me that the method is not a compareTo at all...
that its a kind of hasEnough test.  Might be nice having the version code all up inside the
hasEnough method.

Erik, how do you figure this code makes things faster.  Its not plain to me how it does that.

> 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,
> 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,

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

View raw message