Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of sebastian.estevez@datastax.com
 designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALAVqMuxTLx3W2-1qjKYCoYA_nvwK3edzCZQpeV6QNQ5dgCwRw@mail.gmail.com>
References: 
 <CALAVqMuxTLx3W2-1qjKYCoYA_nvwK3edzCZQpeV6QNQ5dgCwRw@mail.gmail.com>
Date: Tue, 16 Jun 2015 10:10:37 -0400
Message-ID: 
 <CACCmCN-d4DXA=o3Rk=cdz8TYm2-CU81b_6wqrO7tV32XQNPa4w@mail.gmail.com>
Subject: Re: Tuning Cassandra 2.1 for High Writes and Immediate Reads
From: Sebastian Estevez <sebastian.estevez@datastax.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=f46d044304407d300c0518a323c3

--f46d044304407d300c0518a323c3
Content-Type: text/plain; charset=UTF-8

If you use clustering order by and need to keep the top rows in cache, look
at the row cache in 2.1.

http://www.datastax.com/dev/blog/row-caching-in-cassandra-2-1
On Jun 16, 2015 5:39 AM, "Pracheer Agarwal" <pracheeragarwal@gmail.com>
wrote:

> Hi,
>
> We are evaluating Cassandra 2.1 for our new production system. The
> following are the requirements:
>
> 1. 15K writes/sec with 5 KB blob in a single column of a column family,
> 2. This is followed by immediate Reads by multiple consumer threads, the
> read requires us to return entire Row and not only the recently updated
> column.
> 3. Around 1B unique keys.
>
> So I am assuming for the reads the data can be fetched from both Memtable
> (if it is not flushed) and Key-cache. (Row-cache is disabled)
>
> How can we optimize for higher Read throughput at the cost of Writes?
>
> Machine configuration, 10 Node cluster.
>
>    - 24 core/machine
>    - 64 GB RAM
>    - 2TB*5 HDD per machine
>    - 10G NIC
>
>
> Till now, for optimization we have done the following:
> 1. We have provided 4G keycache.
> 2. Created parition-key and clustering key in such a way that, for every
> new event a new cell is created, we never update a record.
> 3. No light-weight transactions
> 4. ReplicationFactor 3
> 5. Write quorum 2, Read quorum 2
>
> How can we further optimize for the write/read patterns explained above?
>
> Thanks,
> Pracheer
>

--f46d044304407d300c0518a323c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">If you use clustering order by and need to keep the top rows=
 in cache, look at the row cache in 2.1. </p>
<p dir=3D"ltr"><a href=3D"http://www.datastax.com/dev/blog/row-caching-in-c=
assandra-2-1">http://www.datastax.com/dev/blog/row-caching-in-cassandra-2-1=
</a></p>
<div class=3D"gmail_quote">On Jun 16, 2015 5:39 AM, &quot;Pracheer Agarwal&=
quot; &lt;<a href=3D"mailto:pracheeragarwal@gmail.com">pracheeragarwal@gmai=
l.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Hi,<div><br></div><div>We are evaluating Cassandra 2.1 fo=
r our new production system. The following are the requirements:</div><div>=
<br></div><div>1. 15K writes/sec with 5 KB blob in a single column of a col=
umn family,=C2=A0</div><div>2. This is followed by immediate Reads by multi=
ple consumer threads, the read requires us to return entire Row and not onl=
y the recently updated column.</div><div>3. Around 1B unique keys.</div><di=
v><br></div><div>So I am assuming for the reads the data can be fetched fro=
m both Memtable (if it is not flushed) and Key-cache. (Row-cache is disable=
d)=C2=A0</div><div><br></div><div>How can we optimize for higher Read throu=
ghput at the cost of Writes?</div><div><br></div><div>Machine configuration=
, 10 Node cluster.</div><div><ul><li>24 core/machine</li><li>64 GB RAM</li>=
<li>2TB*5 HDD per machine</li><li>10G NIC=C2=A0</li></ul></div><div><br></d=
iv><div>Till now, for optimization we have done the following:</div><div>1.=
 We have provided 4G keycache.</div><div>2. Created parition-key and cluste=
ring key in such a way that, for every new event a new cell is created, we =
never update a record.</div><div>3. No light-weight transactions</div><div>=
4. ReplicationFactor 3</div><div>5. Write quorum 2, Read quorum 2</div><div=
><br></div><div>How can we further optimize for the write/read patterns exp=
lained above?</div><div><br></div><div>Thanks,</div><div>Pracheer</div></di=
v>
</blockquote></div>

--f46d044304407d300c0518a323c3--