[ 
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669127#action_12669127
 ] 

Erik Holstad commented on HBASE-880:
------------------------------------

We have a use case where we for one column family have a lot of columns like 
10000. They are time sorted on the column name
where the timestamp is one part of the column qualifier, so that you get the 
latest actions first. So if we are using getRow() to get
a row but are only planning to use let's say the first 100 columns in the 
family we still need to fetch the whole row from the server
and then take care of the "filtering" client side. Would be useful for us to 
have something like a getRow() with a filter option so
that the filtering can take place server side instead, to speed things up, 
maybe something like what exists for scanners a the moment.

> Improve the current client API by creating new container classes
> ----------------------------------------------------------------
>
>                 Key: HBASE-880
>                 URL: https://issues.apache.org/jira/browse/HBASE-880
>             Project: Hadoop HBase
>          Issue Type: Improvement
>          Components: client
>            Reporter: Jean-Daniel Cryans
>            Assignee: Jean-Daniel Cryans
>             Fix For: 0.20.0
>
>         Attachments: 880.patch, 880proposal4plus-v2.patch, 
> 880proposal4plus.patch, 880proposal5-v2.patch, 880proposal5-v2.png, 
> 880proposal5.patch, 880proposal5.png, hbase-880-patch.jpg, 
> hbase-880-proposal4.patch, hbase-880-v1.patch, hbase-880-v2.patch, 
> hbase_client_classes.png, NewCilentAPIProposoal4.gif, proposal2.jpg, 
> proposed.jpg
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> The current API does not scale very well. For each new feature, we have to 
> add many methods to take care of all the overloads. Also, the need to batch 
> row operations (gets, inserts, deletes) implies that we have to manage some 
> "entities" like we are able to do with BatchUpdate but not with the other 
> operations. The RowLock should be an attribute of such an entity.
> The scope of this jira is only to replace current API with another 
> feature-compatible one, other methods will be added in other issues.

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

Reply via email to