hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-54) SequenceFile should compress blocks, not individual entries
Date Sun, 16 Jul 2006 06:00:15 GMT
    [ http://issues.apache.org/jira/browse/HADOOP-54?page=comments#action_12421380 ] 
Bryan Pendleton commented on HADOOP-54:

Another feature that might be useful: include an (optional) un-compressed copy of the *last*
key in a given compression spill. Why? Because, for sorted SequenceFiles (specifically, for
the data file of a MapFile), when seeking through to find a given key/value, knowing the last
key in a given chunk allows skipping of decompressing the entire key array.

It should, of course, be optional, both because keys potentially be large, and because SequenceFiles
aren't all sorted. But, in the MapFile case, it could reduce the cost of finding a hit during

Might also be useful to try to do some DFS block-aligning, to avoid block requests and CRC
calculations for data that's not really going to be used. That sounds like it might be tricky
to get, though, because default GFS blocks are so large, and we're probably talking about
much smaller compression chunks. Does DFS have variable-length block writing yet?

> 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: Michel Tourn
>             Fix For: 0.5.0
> 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


View raw message