cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Nikam <skni...@gmail.com>
Subject Re: Cassandra Data Stax java driver & Snappy Compression library
Date Wed, 05 Aug 2015 03:34:35 GMT
Janne,
A little clarification i found snappy-java-1.0.4.1.jar on class path. But
other questions still remain.

On Tue, Aug 4, 2015 at 8:24 PM, Sachin Nikam <sknikam@gmail.com> wrote:

> 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 <janne.jalkanen@ecyrd.com>
> wrote:
>
>>
>> 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 now.
>>
>> /Janne
>>
>> On 3 Aug 2015, at 08:40, Sachin Nikam <sknikam@gmail.com> wrote:
>>
>> 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 <Janne.Jalkanen@ecyrd.com
>> > wrote:
>>
>>> 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 <sknikam@gmail.com> wrote:
>>>
>>> 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 library.
>>>
>>> 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 --
>>>
>>> http://stackoverflow.com/questions/21784149/getting-cassandra-connection-error
>>> #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
>>>
>>>
>>>
>>
>>
>

Mime
View raw message