[ 
http://issues.apache.org/jira/browse/HADOOP-54?page=comments#action_12423218 ] 
            
eric baldeschwieler commented on HADOOP-54:
-------------------------------------------

I completely agree that you should incrementally decompress.  The right answer 
might be just enough for the next entry or a small buffer,  should performance 
test that.

My point on raw is that you can return a reference tuple in an object:

   <raw bytes,is compressed flag, compressor class> used in a reference

Then you read the bytes, decompressed if they come from a block compressed or 
an uncompressed file, compressed if they come from an item compressed file.

Then you pass this reference to the target sequence file's raw write method.  
The target then compresses or decompresses as needed.

Since you package all of this up behind an API, folks will not get confused 
into using this essentially internal API to do the wrong thing  and it will 
efficiently passed item compressed objects from one such stream to another if 
given the chance.

This may be worth considering, since sorts and merges may often operate on item 
compressed values and this will avoid a lot of spurious 
decompression/compression.

PS we probably should only bother doing this for values.


> SequenceFile should compress blocks, not individual entries
> -----------------------------------------------------------
>
>                 Key: HADOOP-54
>                 URL: http://issues.apache.org/jira/browse/HADOOP-54
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: io
>    Affects Versions: 0.2.0
>            Reporter: Doug Cutting
>         Assigned To: Arun C Murthy
>             Fix For: 0.5.0
>
>         Attachments: VIntCompressionResults.txt
>
>
> SequenceFile will optionally compress individual values.  But both 
> compression and performance would be much better if sequences of keys and 
> values are compressed together.  Sync marks should only be placed between 
> blocks.  This will require some changes to MapFile too, so that all file 
> positions stored there are the positions of blocks, not entries within 
> blocks.  Probably this can be accomplished by adding a 
> getBlockStartPosition() method to SequenceFile.Writer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to