Depending on the compression rate, I think it would generate less garbage on the Cassandra side if you compressed it client side. Something to test out.
> On Apr 4, 2018, at 7:19 AM, Jeff Jirsa <jji...@gmail.com> wrote: > > Compressing server side and validating checksums is hugely important in the > more frequently used versions of cassandra - so since you probably want to > run compression on the server anyway, I’m not sure why you’d compress it > twice > > -- > Jeff Jirsa > > > On Apr 4, 2018, at 6:23 AM, DuyHai Doan <doanduy...@gmail.com > <mailto:doanduy...@gmail.com>> wrote: > >> Compressing client-side is better because it will save: >> >> 1) a lot of bandwidth on the network >> 2) a lot of Cassandra CPU because no decompression server-side >> 3) a lot of Cassandra HEAP because the compressed blob should be relatively >> small (text data compress very well) compared to the raw size >> >> On Wed, Apr 4, 2018 at 2:59 PM, Jeronimo de A. Barros >> <jeronimo.bar...@gmail.com <mailto:jeronimo.bar...@gmail.com>> wrote: >> Hi, >> >> We use a pseudo file-system table where the chunks are blobs of 64 KB and we >> never had any performance issue. >> >> Primary-key structure is ((file-uuid), chunck-id). >> >> Jero >> >> On Wed, Apr 4, 2018 at 9:25 AM, shalom sagges <shalomsag...@gmail.com >> <mailto:shalomsag...@gmail.com>> wrote: >> Hi All, >> >> A certain application is writing ~55,000 characters for a single row. Most >> of these characters are entered to one column with "text" data type. >> >> This looks insanely large for one row. >> Would you suggest to change the data type from "text" to BLOB or any other >> option that might fit this scenario? >> >> Thanks! >> >>
