hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7978) Merge hbase-prefixtree into hbase-server
Date Sat, 02 Mar 2013 09:51:13 GMT

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

Enis Soztutar commented on HBASE-7978:
--------------------------------------

bq. Can you cite some literature supporting the above view ?
Importing hadoop trunk into eclipse... Do you need more? 
bq. I'm confused about the issue title Enis - why merge to hbase-server when it will immediately
go in hbase-storage?
The title states what can be done in this issue. hbase-storage is a longer term goal, which
might or might not happen later on. If it happens, we can just move the code there with the
rest of the storage stuff. 
bq. In my mind it was something like hbase-codec. In fact, the prefix-tree code is nested
in a package called o.a.h.h.codec, as is Stack's RPC serialization code. The idea being that
hbase-common contains interfaces for different things that get encoded as opaque byte arrays,
such as data blocks, bloom blocks, index blocks, rpc chunks, etc
My understanding of the current DBE is that it is not suitable to be used outside an HFile
block setting. I agree that we should extend these to support encoding bulks of cells, no
matter the context (rpc, hfile, etc). I would be fine if we do a codec module, if we include
all of the codecs, but -1 for having a module per codec type. We also need some sanity to
be able to browse the code from IDE. Also, for generating hfiles for bulk load, then you have
to dynamically link that appropriate codec jar into your mapreduce job, which is not a thing
we would want.
The question here is whether to rename the current module to hbase-codec and have the rest
there? How close are we do extract the DBE as generic codecs? 


                
> Merge hbase-prefixtree into hbase-server
> ----------------------------------------
>
>                 Key: HBASE-7978
>                 URL: https://issues.apache.org/jira/browse/HBASE-7978
>             Project: HBase
>          Issue Type: Improvement
>          Components: HFile
>    Affects Versions: 0.95.0, 0.98.0
>            Reporter: Enis Soztutar
>
> I would like to discuss the possibility of merging the prefix tree module into the hbase-server
module. 
> Ideally, I think we should have hbase-mapreduce and hbase-storage modules, the latter
one containing most of HFile code. hbase-mapreduce depends on hbase-storage so that it knows
how to encode hfiles. prefix-tree belongs to hbase-storage. 
> prefix tree is just another DBE, although a big one, and it rightfully belongs with her
sisters. The fact that the code is independent from the rest of the code base does not mean
that it should have it's own module. We should keep the number of modules manageable, and
stay away from hadoop trunk's one-module-per-package policy. 
> Related: HBASE-7936

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message