Are Cassandra writes are faster than reads?

[Vikas Jaiman]

Hi all,

Are Cassandra writes are faster than reads ?? If yes, why is this so? I am
using consistency 1 and data is in memory.

Vikas

Re: Are Cassandra writes are faster than reads?

[Jeff Jirsa]

Cassandra writes are particularly fast, for a few reasons:

 

1)   Most writes go to a commitlog (append-only file, written linearly, so 
particularly fast in terms of disk operations) and then pushed to the memTable. 
Memtable is flushed in batches to the permanent data files, so it buffers many 
mutations and then does a sequential write to persist that data to disk.

2)   Reads may have to merge data from many data tables on disk. Because 
the writes (described very briefly in step 1) write to immutable files, 
updates/deletes have to be merged on read – this is extra effort for the read 
path.

 

If you don’t do much in terms of overwrites/deletes, and your partitions are 
particularly small, and your data fits in RAM (probably mmap/page cache of data 
files, unless you’re using the row cache), reads may be very fast for you. 
Certainly individual reads on low-merge workloads can be < 0.1ms.

 

-  Jeff

 

From: Vikas Jaiman 
Reply-To: "user@cassandra.apache.org" 
Date: Sunday, November 6, 2016 at 12:42 PM
To: "user@cassandra.apache.org" 
Subject: Are Cassandra writes are faster than reads?

 

Hi all,

 

Are Cassandra writes are faster than reads ?? If yes, why is this so? I am 
using consistency 1 and data is in memory. 

 

Vikas



smime.p7s
Description: S/MIME cryptographic signature

Designing a table in cassandra

[sat]

Hi,

We are new to Cassandra. For our POC, we tried creating table and inserting
them as JSON and all these went fine. Now we are trying to implement one of
the application scenario, and I am having difficulty in coming up with the
best approach.

Scenario:
We have a Device POJO which have some attributes/fields which are
read/write by users as well as network and some attributes/fields only
network can modify. When users need to configure they will create an
instance of Device POJO and set/configure applicable fields, however
network can update those attributes. We wanted to know the discrepancy by
the values configured by users versus the values updated by network. Hence
we have thought of 3 different approaches

1) Create multiple tables for the same Device like Device_Users and
Device_Network so that we can see the difference.

2) Create different Keyspace as multiple objects like Device can have the
same requirement

3) Create one "Device" table and insert one row for user configuration and
another row for network update. We will create this table with multiple
primary key (device_name, updated_by)

Please let us know which is the best option (with their pros and cons if
possible) among these 3, and also let us know if there are other options.

Thanks and Regards
A.SathishKumar

Re: Are Cassandra writes are faster than reads?

[Ben Bromhead]

To add some flavor as to how the commitlog implementation is so quick.

It only flushes to disk every 10s by default. So writes are effectively
done to memory and then to disk asynchronously later on. This is generally
accepted to be OK, as the write is also going to other nodes.

You can of course change this behavior to flush on each write or to skip
the commitlog altogether (danger!). This however will change how "safe"
things are from a durability perspective.

On Sun, Nov 6, 2016, 12:51 Jeff Jirsa  wrote:

> Cassandra writes are particularly fast, for a few reasons:
>
>
>
> 1)   Most writes go to a commitlog (append-only file, written
> linearly, so particularly fast in terms of disk operations) and then pushed
> to the memTable. Memtable is flushed in batches to the permanent data
> files, so it buffers many mutations and then does a sequential write to
> persist that data to disk.
>
> 2)   Reads may have to merge data from many data tables on disk.
> Because the writes (described very briefly in step 1) write to immutable
> files, updates/deletes have to be merged on read – this is extra effort for
> the read path.
>
>
>
> If you don’t do much in terms of overwrites/deletes, and your partitions
> are particularly small, and your data fits in RAM (probably mmap/page cache
> of data files, unless you’re using the row cache), reads may be very fast
> for you. Certainly individual reads on low-merge workloads can be < 0.1ms.
>
>
>
> -  Jeff
>
>
>
> *From: *Vikas Jaiman 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Sunday, November 6, 2016 at 12:42 PM
> *To: *"user@cassandra.apache.org" 
> *Subject: *Are Cassandra writes are faster than reads?
>
>
>
> Hi all,
>
>
>
> Are Cassandra writes are faster than reads ?? If yes, why is this so? I am
> using consistency 1 and data is in memory.
>
>
>
> Vikas
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Is it a memory issue?

[wxn...@zjqunshuo.com]

Hi All,
We have one issue on C* testing. At first the inserting was very fast and TPS 
was about 30K/s, but when the size of data rows reached 2 billion, the 
insertion rate decreased very badly and the TPS was 20K/s. When the size of 
rows reached 2.3 billion, the TPS decreased to 0.5K/s, and writing timeout come 
out. At last OOM issue happened in some nodes and C* deamon in some nodes 
crashed.  In production we have about 8 billion rows. My testing cluster 
setting is as below. My question is if the memory is the main issue. Do I need 
increase the memory, and what's the right setting for MAX_HEAP_SIZE and 
HEAP_NEWSIZE?

My cluster setting:
C* cluster with 3 nodes in Aliyun Cloud
CPU: 4core
Memory: 8G
Disk: 500G
MAX_HEAP_SIZE=2G
HEAP_NEWSIZE=500M

My table schema:
CREATE KEYSPACE IF NOT EXISTS cargts WITH REPLICATION = {'class': 
'SimpleStrategy','replication_factor':2};
use cargts;
CREATE TABLE eventdata (
deviceId int,
date int,
event_time bigint,
lat decimal,
lon decimal,
speed int,
heading int,
PRIMARY KEY ((deviceId,date),event_time)
)
WITH CLUSTERING ORDER BY (event_time ASC);
CREATE INDEX ON eventdata (event_time);

Best Regards,
-Simon Wu

Re: Is it a memory issue?

[Ben Slater]

This sounds to me like your writes go ahead of compactions trying to keep
up which can eventually cause issues. Keep an eye on nodetool
compactionstats if the number of compactions continually climbs then you
are writing faster than Cassandra can actually process. If this is
happening then you need to either add more processing capacity (nodes) to
your cluster or throttle writes on the client side.

It could also be related to conditions like an individual partition growing
too big but I’d check for backed up compactions first.

Cheers
Ben

On Mon, 7 Nov 2016 at 14:17 wxn...@zjqunshuo.com 
wrote:

> Hi All,
> We have one issue on C* testing. At first the inserting was very fast and
> TPS was about 30K/s, but when the size of data rows reached 2 billion, the
> insertion rate decreased very badly and the TPS was 20K/s. When the size of
> rows reached 2.3 billion, the TPS decreased to 0.5K/s, and writing timeout
> come out. At last OOM issue happened in some nodes and C* deamon in some
> nodes crashed.  In production we have about 8 billion rows. My testing
> cluster setting is as below. My question is if the memory is the main
> issue. Do I need increase the memory, and what's the right setting for 
> MAX_HEAP_SIZE
> and HEAP_NEWSIZE?
>
> My cluster setting:
> C* cluster with 3 nodes in Aliyun Cloud
> CPU: 4core
> Memory: 8G
> Disk: 500G
> MAX_HEAP_SIZE=2G
> HEAP_NEWSIZE=500M
>
> My table schema:
>
> CREATE KEYSPACE IF NOT EXISTS cargts WITH REPLICATION = {'class': 
> 'SimpleStrategy','replication_factor':2};
> use cargts;
> CREATE TABLE eventdata (
> deviceId int,
> date int,
> event_time bigint,
> lat decimal,
> lon decimal,
> speed int,
> heading int,
> PRIMARY KEY ((deviceId,date),event_time)
> )
> WITH CLUSTERING ORDER BY (event_time ASC);
> CREATE INDEX ON eventdata (event_time);
>
> Best Regards,
> -Simon Wu
>
>

Re: Are Cassandra writes are faster than reads?

[Ali Akhtar]

How long does it take for updates to get merged / compacted into the main
data file?

On Mon, Nov 7, 2016 at 5:31 AM, Ben Bromhead  wrote:

> To add some flavor as to how the commitlog implementation is so quick.
>
> It only flushes to disk every 10s by default. So writes are effectively
> done to memory and then to disk asynchronously later on. This is generally
> accepted to be OK, as the write is also going to other nodes.
>
> You can of course change this behavior to flush on each write or to skip
> the commitlog altogether (danger!). This however will change how "safe"
> things are from a durability perspective.
>
> On Sun, Nov 6, 2016, 12:51 Jeff Jirsa  wrote:
>
>> Cassandra writes are particularly fast, for a few reasons:
>>
>>
>>
>> 1)   Most writes go to a commitlog (append-only file, written
>> linearly, so particularly fast in terms of disk operations) and then pushed
>> to the memTable. Memtable is flushed in batches to the permanent data
>> files, so it buffers many mutations and then does a sequential write to
>> persist that data to disk.
>>
>> 2)   Reads may have to merge data from many data tables on disk.
>> Because the writes (described very briefly in step 1) write to immutable
>> files, updates/deletes have to be merged on read – this is extra effort for
>> the read path.
>>
>>
>>
>> If you don’t do much in terms of overwrites/deletes, and your partitions
>> are particularly small, and your data fits in RAM (probably mmap/page cache
>> of data files, unless you’re using the row cache), reads may be very fast
>> for you. Certainly individual reads on low-merge workloads can be < 0.1ms.
>>
>>
>>
>> -  Jeff
>>
>>
>>
>> *From: *Vikas Jaiman 
>> *Reply-To: *"user@cassandra.apache.org" 
>> *Date: *Sunday, November 6, 2016 at 12:42 PM
>> *To: *"user@cassandra.apache.org" 
>> *Subject: *Are Cassandra writes are faster than reads?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Are Cassandra writes are faster than reads ?? If yes, why is this so? I
>> am using consistency 1 and data is in memory.
>>
>>
>>
>> Vikas
>>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>

Re: Are Cassandra writes are faster than reads?

[Ben Bromhead]

Check out https://wiki.apache.org/cassandra/WritePathForUsers for the full
gory details.

On Sun, 6 Nov 2016 at 21:09 Ali Akhtar  wrote:

> How long does it take for updates to get merged / compacted into the main
> data file?
>
> On Mon, Nov 7, 2016 at 5:31 AM, Ben Bromhead  wrote:
>
> To add some flavor as to how the commitlog implementation is so quick.
>
> It only flushes to disk every 10s by default. So writes are effectively
> done to memory and then to disk asynchronously later on. This is generally
> accepted to be OK, as the write is also going to other nodes.
>
> You can of course change this behavior to flush on each write or to skip
> the commitlog altogether (danger!). This however will change how "safe"
> things are from a durability perspective.
>
> On Sun, Nov 6, 2016, 12:51 Jeff Jirsa  wrote:
>
> Cassandra writes are particularly fast, for a few reasons:
>
>
>
> 1)   Most writes go to a commitlog (append-only file, written
> linearly, so particularly fast in terms of disk operations) and then pushed
> to the memTable. Memtable is flushed in batches to the permanent data
> files, so it buffers many mutations and then does a sequential write to
> persist that data to disk.
>
> 2)   Reads may have to merge data from many data tables on disk.
> Because the writes (described very briefly in step 1) write to immutable
> files, updates/deletes have to be merged on read – this is extra effort for
> the read path.
>
>
>
> If you don’t do much in terms of overwrites/deletes, and your partitions
> are particularly small, and your data fits in RAM (probably mmap/page cache
> of data files, unless you’re using the row cache), reads may be very fast
> for you. Certainly individual reads on low-merge workloads can be < 0.1ms.
>
>
>
> -  Jeff
>
>
>
> *From: *Vikas Jaiman 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Sunday, November 6, 2016 at 12:42 PM
> *To: *"user@cassandra.apache.org" 
> *Subject: *Are Cassandra writes are faster than reads?
>
>
>
> Hi all,
>
>
>
> Are Cassandra writes are faster than reads ?? If yes, why is this so? I am
> using consistency 1 and data is in memory.
>
>
>
> Vikas
>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Re: Are Cassandra writes are faster than reads?

[Ali Akhtar]

tl;dr? I just want to know if updates are bad for performance, and if so,
for how long.

On Mon, Nov 7, 2016 at 10:23 AM, Ben Bromhead  wrote:

> Check out https://wiki.apache.org/cassandra/WritePathForUsers for the
> full gory details.
>
> On Sun, 6 Nov 2016 at 21:09 Ali Akhtar  wrote:
>
>> How long does it take for updates to get merged / compacted into the main
>> data file?
>>
>> On Mon, Nov 7, 2016 at 5:31 AM, Ben Bromhead  wrote:
>>
>> To add some flavor as to how the commitlog implementation is so quick.
>>
>> It only flushes to disk every 10s by default. So writes are effectively
>> done to memory and then to disk asynchronously later on. This is generally
>> accepted to be OK, as the write is also going to other nodes.
>>
>> You can of course change this behavior to flush on each write or to skip
>> the commitlog altogether (danger!). This however will change how "safe"
>> things are from a durability perspective.
>>
>> On Sun, Nov 6, 2016, 12:51 Jeff Jirsa  wrote:
>>
>> Cassandra writes are particularly fast, for a few reasons:
>>
>>
>>
>> 1)   Most writes go to a commitlog (append-only file, written
>> linearly, so particularly fast in terms of disk operations) and then pushed
>> to the memTable. Memtable is flushed in batches to the permanent data
>> files, so it buffers many mutations and then does a sequential write to
>> persist that data to disk.
>>
>> 2)   Reads may have to merge data from many data tables on disk.
>> Because the writes (described very briefly in step 1) write to immutable
>> files, updates/deletes have to be merged on read – this is extra effort for
>> the read path.
>>
>>
>>
>> If you don’t do much in terms of overwrites/deletes, and your partitions
>> are particularly small, and your data fits in RAM (probably mmap/page cache
>> of data files, unless you’re using the row cache), reads may be very fast
>> for you. Certainly individual reads on low-merge workloads can be < 0.1ms.
>>
>>
>>
>> -  Jeff
>>
>>
>>
>> *From: *Vikas Jaiman 
>> *Reply-To: *"user@cassandra.apache.org" 
>> *Date: *Sunday, November 6, 2016 at 12:42 PM
>> *To: *"user@cassandra.apache.org" 
>> *Subject: *Are Cassandra writes are faster than reads?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Are Cassandra writes are faster than reads ?? If yes, why is this so? I
>> am using consistency 1 and data is in memory.
>>
>>
>>
>> Vikas
>>
>> --
>> Ben Bromhead
>> CTO | Instaclustr 
>> +1 650 284 9692
>> Managed Cassandra / Spark on AWS, Azure and Softlayer
>>
>>
>> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>

Re: Is it a memory issue?

[wxn...@zjqunshuo.com]

Thanks Ben. I stopped inserting and checked compaction status as you mentioned. 
Seems there is lots of compaction work waiting to do. Please see below. In this 
case is it a sign that writting faster than C* can process?

One node,
[root@iZbp11zpafrqfsiys90kzoZ bin]# ./nodetool compactionstats
pending tasks: 195
 id   compaction type   keyspace
tablecompleted totalunit   progress
   5da60b10-a4a9-11e6-88e9-755b5673a02aCompaction cargts   
eventdata.eventdata_event_time_idx   1699866872   26536427792   bytes  6.41%
   Compaction system
hints 103543795172210360   bytes  0.20%
Active compaction remaining time :   0h29m48s

Another node,
[root@iZbp1iqnrpsdhoodwii32bZ bin]# ./nodetool compactionstats
pending tasks: 84
 id   compaction type   keyspace
table completed totalunit   progress
   28a9d010-a4a7-11e6-b985-979fea8d6099Compaction cargts
eventdata 6561414001424412420   bytes 46.06%
   7c034840-a48e-11e6-b985-979fea8d6099Compaction cargts   
eventdata.eventdata_event_time_idx   32098562606   42616107664   bytes 
75.32%
Active compaction remaining time :   0h11m12s
 
From: Ben Slater
Date: 2016-11-07 11:41
To: user
Subject: Re: Is it a memory issue?
This sounds to me like your writes go ahead of compactions trying to keep up 
which can eventually cause issues. Keep an eye on nodetool compactionstats if 
the number of compactions continually climbs then you are writing faster than 
Cassandra can actually process. If this is happening then you need to either 
add more processing capacity (nodes) to your cluster or throttle writes on the 
client side.

It could also be related to conditions like an individual partition growing too 
big but I’d check for backed up compactions first.

Cheers
Ben

On Mon, 7 Nov 2016 at 14:17 wxn...@zjqunshuo.com  wrote:
Hi All,
We have one issue on C* testing. At first the inserting was very fast and TPS 
was about 30K/s, but when the size of data rows reached 2 billion, the 
insertion rate decreased very badly and the TPS was 20K/s. When the size of 
rows reached 2.3 billion, the TPS decreased to 0.5K/s, and writing timeout come 
out. At last OOM issue happened in some nodes and C* deamon in some nodes 
crashed.  In production we have about 8 billion rows. My testing cluster 
setting is as below. My question is if the memory is the main issue. Do I need 
increase the memory, and what's the right setting for MAX_HEAP_SIZE and 
HEAP_NEWSIZE?

My cluster setting:
C* cluster with 3 nodes in Aliyun Cloud
CPU: 4core
Memory: 8G
Disk: 500G
MAX_HEAP_SIZE=2G
HEAP_NEWSIZE=500M

My table schema:
CREATE KEYSPACE IF NOT EXISTS cargts WITH REPLICATION = {'class': 
'SimpleStrategy','replication_factor':2};
use cargts;
CREATE TABLE eventdata (
deviceId int,
date int,
event_time bigint,
lat decimal,
lon decimal,
speed int,
heading int,
PRIMARY KEY ((deviceId,date),event_time)
)
WITH CLUSTERING ORDER BY (event_time ASC);
CREATE INDEX ON eventdata (event_time);

Best Regards,
-Simon Wu

Re: Is it a memory issue?

[Ben Slater]

Yes, it does mean you’re getting ahead of Cassandra’s ability to keep up
although I would have probably expected a higher number of pending
compactions before you got serious issues (I’ve seen numbers in the
thousands).

I notice from the screenshot you provide that you are using secondary
indexes. There are a lot of way to missuse secondary indexes (vs not very
many way to use them well). I think it’s possible that what you are seeing
is the result of the secondary index on event time (I assume a very high
cardinality column). This is a good blog on secondary indexes:
http://www.wentnet.com/blog/?p=77

Cheers
Ben

On Mon, 7 Nov 2016 at 16:29 wxn...@zjqunshuo.com 
wrote:

> Thanks Ben. I stopped inserting and checked compaction status as you
> mentioned. Seems there is lots of compaction work waiting to do. Please see
> below. In this case is it a sign that writting faster than C* can process?
>
> One node,
> [root@iZbp11zpafrqfsiys90kzoZ bin]# ./nodetool compactionstats
> pending tasks: 195
>
>  id   compaction type   keyspace  
>   tablecompleted totalunit   progress
>
>5da60b10-a4a9-11e6-88e9-755b5673a02aCompaction cargts   
> eventdata.eventdata_event_time_idx   1699866872   26536427792   bytes  
> 6.41%
>
>Compaction system  
>   hints 103543795172210360   bytes  0.20%
> Active compaction remaining time :   0h29m48s
>
> Another node,
> [root@iZbp1iqnrpsdhoodwii32bZ bin]# ./nodetool compactionstats
> pending tasks: 84
>
>  id   compaction type   keyspace  
>   table completed totalunit   progress
>
>28a9d010-a4a7-11e6-b985-979fea8d6099Compaction cargts  
>   eventdata 6561414001424412420   bytes 46.06%
>
>7c034840-a48e-11e6-b985-979fea8d6099Compaction cargts   
> eventdata.eventdata_event_time_idx   32098562606   42616107664   bytes 
> 75.32%
> Active compaction remaining time :   0h11m12s
>
>
> *From:* Ben Slater 
> *Date:* 2016-11-07 11:41
> *To:* user 
> *Subject:* Re: Is it a memory issue?
>
> This sounds to me like your writes go ahead of compactions trying to keep
> up which can eventually cause issues. Keep an eye on nodetool
> compactionstats if the number of compactions continually climbs then you
> are writing faster than Cassandra can actually process. If this is
> happening then you need to either add more processing capacity (nodes) to
> your cluster or throttle writes on the client side.
>
> It could also be related to conditions like an individual partition
> growing too big but I’d check for backed up compactions first.
>
> Cheers
> Ben
>
> On Mon, 7 Nov 2016 at 14:17 wxn...@zjqunshuo.com 
> wrote:
>
> Hi All,
> We have one issue on C* testing. At first the inserting was very fast and
> TPS was about 30K/s, but when the size of data rows reached 2 billion, the
> insertion rate decreased very badly and the TPS was 20K/s. When the size of
> rows reached 2.3 billion, the TPS decreased to 0.5K/s, and writing timeout
> come out. At last OOM issue happened in some nodes and C* deamon in some
> nodes crashed.  In production we have about 8 billion rows. My testing
> cluster setting is as below. My question is if the memory is the main
> issue. Do I need increase the memory, and what's the right setting for 
> MAX_HEAP_SIZE
> and HEAP_NEWSIZE?
>
> My cluster setting:
> C* cluster with 3 nodes in Aliyun Cloud
> CPU: 4core
> Memory: 8G
> Disk: 500G
> MAX_HEAP_SIZE=2G
> HEAP_NEWSIZE=500M
>
> My table schema:
>
> CREATE KEYSPACE IF NOT EXISTS cargts WITH REPLICATION = {'class': 
> 'SimpleStrategy','replication_factor':2};
> use cargts;
> CREATE TABLE eventdata (
> deviceId int,
> date int,
> event_time bigint,
> lat decimal,
> lon decimal,
> speed int,
> heading int,
> PRIMARY KEY ((deviceId,date),event_time)
> )
> WITH CLUSTERING ORDER BY (event_time ASC);
> CREATE INDEX ON eventdata (event_time);
>
> Best Regards,
> -Simon Wu
>
>

Re: Are Cassandra writes are faster than reads?

[Ben Bromhead]

They can be and it depends on your compaction strategy :)

On Sun, 6 Nov 2016 at 21:24 Ali Akhtar  wrote:

> tl;dr? I just want to know if updates are bad for performance, and if so,
> for how long.
>
> On Mon, Nov 7, 2016 at 10:23 AM, Ben Bromhead  wrote:
>
> Check out https://wiki.apache.org/cassandra/WritePathForUsers for the
> full gory details.
>
> On Sun, 6 Nov 2016 at 21:09 Ali Akhtar  wrote:
>
> How long does it take for updates to get merged / compacted into the main
> data file?
>
> On Mon, Nov 7, 2016 at 5:31 AM, Ben Bromhead  wrote:
>
> To add some flavor as to how the commitlog implementation is so quick.
>
> It only flushes to disk every 10s by default. So writes are effectively
> done to memory and then to disk asynchronously later on. This is generally
> accepted to be OK, as the write is also going to other nodes.
>
> You can of course change this behavior to flush on each write or to skip
> the commitlog altogether (danger!). This however will change how "safe"
> things are from a durability perspective.
>
> On Sun, Nov 6, 2016, 12:51 Jeff Jirsa  wrote:
>
> Cassandra writes are particularly fast, for a few reasons:
>
>
>
> 1)   Most writes go to a commitlog (append-only file, written
> linearly, so particularly fast in terms of disk operations) and then pushed
> to the memTable. Memtable is flushed in batches to the permanent data
> files, so it buffers many mutations and then does a sequential write to
> persist that data to disk.
>
> 2)   Reads may have to merge data from many data tables on disk.
> Because the writes (described very briefly in step 1) write to immutable
> files, updates/deletes have to be merged on read – this is extra effort for
> the read path.
>
>
>
> If you don’t do much in terms of overwrites/deletes, and your partitions
> are particularly small, and your data fits in RAM (probably mmap/page cache
> of data files, unless you’re using the row cache), reads may be very fast
> for you. Certainly individual reads on low-merge workloads can be < 0.1ms.
>
>
>
> -  Jeff
>
>
>
> *From: *Vikas Jaiman 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Sunday, November 6, 2016 at 12:42 PM
> *To: *"user@cassandra.apache.org" 
> *Subject: *Are Cassandra writes are faster than reads?
>
>
>
> Hi all,
>
>
>
> Are Cassandra writes are faster than reads ?? If yes, why is this so? I am
> using consistency 1 and data is in memory.
>
>
>
> Vikas
>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>
>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer