cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-2398) Type specific compression
Date Tue, 29 Mar 2011 01:22:05 GMT


Stu Hood updated CASSANDRA-2398:

    Comment: was deleted

(was: 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.)

> Type specific compression
> -------------------------
>                 Key: CASSANDRA-2398
>                 URL:
>             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
> 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
> 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
> public void skip(int version, DataInput from) throws IOException
> {code} 

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message