hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Holstad (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1249) Rearchitecting of server, client, API, key format, etc for 0.20
Date Tue, 10 Mar 2009 20:14:50 GMT

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

Erik Holstad commented on HBASE-1249:
-------------------------------------

Looks good!
A couple of things that I've been thinking about are:
1. For deletes I think it would make sense to not build the delete set alongside but instead
delete the column in the asked for column list. So when going though memCache and the stores,
when coming to a delete, just remove it from the get list.
2. I think that the setting of the timestamp should not be exposed to the user but, be set
by HBase at all times. This limitation simplifies a lot when reasoning about the order across
storefiles and client formats, to make it as fast, early outs and simple, list instead of
map, as possible.
3. The client return type RowResult seems to be a pretty good general purpose return format,
but think we should have an option to get the list<ByteBuffer> instead so that when
you have knowledge about what kind of data that you have in your system you can make the format
much easier, for example if you are asking for 1 row, 1 family, all columns and 1 version
you only need map<qf, value> or a list of tuples.

Looking at the implementation for the KeyValue there are a couple of things that I want to
bring up.
The Type has some unused bits that can be used in the future for different flags, just to
keep in mind.
I've added a new constructor family on my branch in KeyValue that deals with separating the
column into family and qualifier so that we don't need to look for : and then add it back
after we are done. If you still want the : for printing purposes or what not you can put it
in the family.





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


Mime
View raw message