[
https://issues.apache.org/jira/browse/CASSANDRA-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012251#comment-13012251
]
Stu Hood edited comment on CASSANDRA-2398 at 3/29/11 12:31 AM:
---------------------------------------------------------------
Actually, one restriction we should put on the output blob is that it should
start with a length for skipability.
EDIT: rather than requiring a length at the front, could just add skip(version,
DataInput) method which parallels decompress, since some implementations (fixed
length values) will be able to skip efficiently without storing a length.
was (Author: stuhood):
Actually, one restriction we should put on the output blob is that it
should start with a length for skipability.
> Type specific compression
> -------------------------
>
> Key: CASSANDRA-2398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2398
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Affects Versions: 0.8
> Reporter: Stu Hood
> Labels: compression
> Attachments: example.diff
>
>
> Cassandra has a lot of locations that are ripe for type specific compression.
> A short list:
> Indexes
> * Keys compressed as BytesType, which could default to LZO/LZMA
> * Offsets (delta and varint encoding)
> * Column names added by 2319
> Data
> * Keys, columns, timestamps: see
> http://wiki.apache.org/cassandra/FileFormatDesignDoc
> A basic interface for type specific compression could be as simple as:
> {code:java}
> public void compress(int version, Iterator<ByteBuffer> from, int count,
> DataOutput to) throws IOException
> public void decompress(int version, DataInput from, List<ByteBuffer> to)
> throws IOException
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
