cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tatu Saloranta (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-47) SSTable compression
Date Sun, 06 Dec 2009 07:33:21 GMT


Tatu Saloranta commented on CASSANDRA-47:

I just submitted slightly rewritten version of LZF in Voldemort, optimized for specific use
case (straight byte[] -> byte[], no streaming) for Voldemort. If that's the model that'd
be used here (i.e. input size is fully known, no need for streaming) it'd work pretty well
(adding streaming is not difficult, just needs bit more code to work well with all chunk sizes).

>From my testing LZF seems like a very promising candidate for these use cases -- very
fast, overhead generally no larger than parsing overhead for stored conten -- and code is
very simple, so it is a good algorithm to start with.
If more compression is needed other algorithms (like basic deflate (== gzip)) could be plugged
in later on.

Anyway, main problem obviously is not the codec, but if you need any help with LZF codec,
just let me know (or others on voldemort list).

> SSTable compression
> -------------------
>                 Key: CASSANDRA-47
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Eric Evans
>            Priority: Minor
>             Fix For: 0.9
> We should be able to do SSTable compression which would trade CPU for I/O (almost always
a good trade).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message