[
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:
------------------------------
@jon
+ 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 design
+ 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.
@Erik
+ 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, 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.
