cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravikumar Govindarajan <>
Subject Re: Composite Column Types Storage
Date Wed, 12 Sep 2012 14:30:08 GMT
Thanks for the clarification. Even though compression solves disk space
issue, we might still have Memtable bloat right?

There is another issue to be handled for us. The queries are always going
to be range queries with absolute match on part1 and range on part 2 of the
composite columns

Ex: Query <some-key> <Column-part-1> <Start-Id-part-2> <Limit>

Range queries do not use bloom filters. It holds good for composite-columns
also right? I believe I will end up writing BF bytes only to skip it later.

If sharing had been possible, then <Column-part-1> alone could have gone
into the bloom-filter, speeding up my queries really effectively.

But as I understand, there are many levels of nesting possible in a
composite type and casing at every level is a big task

May be casing for the top-level or the first-part should be a good start?


On Wed, Sep 12, 2012 at 5:46 PM, Sylvain Lebresne <>wrote:

> > Is every <string>/<id> combination stored separately in disk
> Yes, each combination is stored separately on disk (the storage engine
> itself doesn't have special casing for composite column, at least not
> yet). But as far as disk space is concerned, I suspect that sstable
> compression makes this largely a non issue.
> --
> Sylvain

View raw message