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? -- Ravi On Wed, Sep 12, 2012 at 5:46 PM, Sylvain Lebresne <sylv...@datastax.com>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 >
