cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: Cassandra Data Stax java driver & Snappy Compression library
Date Wed, 05 Aug 2015 08:22:04 GMT
I’ve never used Astyanax, so it’s difficult to say, but if you can find the snappy-java
in the classpath, it’s quite possible that compression is enabled for S1 and S2 automatically.
You could try removing the snappy jar from S1 and see if that changes the latencies compared
to S2. ;-)

It probably has some impact on end-to-end latency, but there are multiple other things which
also impact latency, such as whether you’re using prepared queries with the Datastax driver,
how large your queries are, etc.  In general the consensus seems to be that using CQL over
the Datastax driver is 1) very fast and since 2.1 of Cassandra, arguably faster than the Thrift
interface that the older clients still use, b) the clarity of the CQL interface gives a productivity
boost for developers and iii) all new features will be implemented using it, so using CQL
is future-proof.


> On 5 Aug 2015, at 06:34, Sachin Nikam <> wrote:
> Janne,
> A little clarification i found snappy-java- on class path. But other questions
still remain.
> On Tue, Aug 4, 2015 at 8:24 PM, Sachin Nikam < <>>
> Janne,
> Thanks for continuing to take the time to answer my queries. We noticed that write latency
(tp99) from Services S1 and S2 is 50% of the write latency (tp99) for Service S3. I also noticed
that S1 and S2, which also use astyanax client library also have compress-lzf.jar on their
class path. Although the table is defined to use Snappy Compression. Is this compression library
or some other transitive dependency pulled in by Astyanax enabling compression of the payload
i.e. sent over the wire and account for the difference in tp99?
> Regards
> Sachin
> On Mon, Aug 3, 2015 at 12:14 AM, Janne Jalkanen < <>>
> Correct. Note that you may lose some performance this way though; in a typical case saving
bandwidth by increasing CPU usage is good. However, it always depends on your usecase and
whether you’re running your cluster to the max. It’s a good, low-hanging optimization
to keep in mind though for production environments, if you choose not to enable compression
> /Janne
>> On 3 Aug 2015, at 08:40, Sachin Nikam < <>>
>> Thanks Janne...
>> To clarify, Service S3 should not run in to any issues and I may choose to not fix
the issue?
>> Regards
>> Sachin
>> On Sat, Aug 1, 2015 at 11:50 PM, Janne Jalkanen < <>>
>> No, this just tells that your client (S3 using Datastax driver) cannot communicate
to the Cassandra cluster using a compressed protocol, since the necessary libraries are missing
on the client side.  Servers will still compress the data they receive when they write it
to disk.
>> In other words
>> Client  <- [uncompressed data] -> Server <- [compressed data] -> Disk.

>> To fix, make sure that the Snappy libraries are in the classpath of your S3 service
application.  As always, there’s no guarantee that this improves your performance, since
if your app is already CPU-heavy, the extra CPU overhead of compression *may* be a problem.
 So measure :-)
>> /Janne
>>> On 02 Aug 2015, at 02:17 , Sachin Nikam < <>>
>>> I am currently running a Cassandra 1.2 cluster. This cluster has 2 tables i.e.
>>> TableA and TableB.
>>> TableA is read and written to by Services S1 and S2 which use Astyanax client
>>> TableB is read and written by Service S3 which uses the datastax java driver
2.1. S3 also reads data from TableA.
>>> Both TableA and TableB are defined on the Cassandra nodes to use SnappyCompressor.
>>> On start-up service, Service S3 throws the following WARNing messages. The service
is able to continue doing its normal operation thereafter
>>> **************
>>> [main] WARN  loggerClass=com.datastax.driver.core.FrameCompressor;Cannot find
Snappy class, you should make sure the Snappy library is in the classpath if you intend to
use it. Snappy compression will not be available for the protocol.
>>> ***********
>>> My questions are as follows--
>>> #1. Does the compression happen on the cassandra client side or within cassandra
server side itself?
>>> #2. Does Service S3 need to pull in additional dependencies for Snappy Compressions
as mentioned here --
>>> #3. What happens without this additional library not being present on class path
of Service S3. Any data that S3 writes to TableB will not be compressed? 
>>> Regards
>>> Sachin

View raw message