Yes. The block size is specified as part of the compression options for the CF / Table.
Cheers ----------------- Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 20/03/2013, at 5:31 AM, Drew Kutcharian <d...@venarc.com> wrote: > Thanks Sylvain. So C* compression is block based and has nothing to do with > format of the rows. > > On Mar 19, 2013, at 1:31 AM, Sylvain Lebresne <sylv...@datastax.com> wrote: > >> That's just describing what compression is about. Compression (not in C*, in >> general) is based on recognizing repeated pattern. >> >> So yes, in that sense, static column families are more likely to yield >> better compression ratio because it is more likely to have repeated patterns >> in the compressed blocks. But: >> 1) it doesn't necessarily mean that wide column families won't have a good >> compression ratio per se. >> 2) you can absolutely have crappy compression ratio with a static column >> family. Just create a column family where each row has 1 column 'image' that >> contains a png. >> >> And to come back to your initial question, I highly doubt disk level >> compression would be much of a workaround because again, that's more about >> how compression is working than how Cassandra use it. >> >> At the end of the day, I really think the best choice is to try it and >> decide for yourself if it does more good than harm or the converse. >> >> -- >> Sylvain >> >> >> On Tue, Mar 19, 2013 at 3:58 AM, Drew Kutcharian <d...@venarc.com> wrote: >> Edward/Sylvain, >> >> I also came across this post on DataStax's blog: >> >>> When to use compression >>> Compression is best suited for ColumnFamilies where there are many rows, >>> with each row having the same columns, or at least many columns in common. >>> For example, a ColumnFamily containing user data such as username, email, >>> etc., would be a good candidate for compression. The more similar the data >>> across rows, the greater the compression ratio will be, and the larger the >>> gain in read performance. >>> Compression is not as good a fit for ColumnFamilies where each row has a >>> different set of columns, or where there are just a few very wide rows. >>> Dynamic column families such as this will not yield good compression ratios. >> >> http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-compression >> >> @Sylvain, does this still apply on more recent versions of C*? >> >> >> -- Drew >> >> >> >> On Mar 18, 2013, at 7:16 PM, Edward Capriolo <edlinuxg...@gmail.com> wrote: >> >>> I feel this has come up before. I believe the compression is block based, >>> so just because no two column names are the same does not mean the >>> compression will not be effective. Possibly in their case the compression >>> was not effective. >>> >>> On Mon, Mar 18, 2013 at 9:08 PM, Drew Kutcharian <d...@venarc.com> wrote: >>> That's what I originally thought but the OOYALA presentation from C*2012 >>> got me confused. Do you guys know what's going on here? >>> >>> The video: >>> http://www.youtube.com/watch?v=r2nGBUuvVmc&feature=player_detailpage#t=790s >>> The slides: Slide 22 @ >>> http://www.datastax.com/wp-content/uploads/2012/08/C2012-Hastur-NoahGibbs.pdf >>> >>> -- Drew >>> >>> >>> On Mar 18, 2013, at 6:14 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: >>> >>>> >>>> Imho it is probably more efficient for wide. When you decompress 8k blocks >>>> to get at a 200 byte row you create overhead , particularly young gen. >>>> On Monday, March 18, 2013, Sylvain Lebresne <sylv...@datastax.com> wrote: >>>> > The way compression is implemented, it is oblivious to the CF being >>>> > wide-row or narrow-row. There is nothing intrinsically less efficient in >>>> > the compression for wide-rows. >>>> > -- >>>> > Sylvain >>>> > >>>> > On Fri, Mar 15, 2013 at 11:53 PM, Drew Kutcharian <d...@venarc.com> >>>> > wrote: >>>> >> >>>> >> Hey Guys, >>>> >> >>>> >> I remember reading somewhere that C* compression is not very effective >>>> >> when most of the CFs are in wide-row format and some folks turn the >>>> >> compression off and use disk level compression as a workaround. >>>> >> Considering that wide rows with composites are "first class citizens" >>>> >> in CQL3, is this still the case? Has there been any improvements on >>>> >> this? >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Drew >>>> > >>> >>> >> >> >
