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 cassandralabs@gmail.com
 designates 209.85.210.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9141AEDC-1C11-4105-B578-3C16B5991C2A@thelastpickle.com>
References: 
 <CAAC9M_3B-9GMjaL+Sxx0Htz2uAS4QCF2vQU0eCtN3=NGwA=ByA@mail.gmail.com>
	<9141AEDC-1C11-4105-B578-3C16B5991C2A@thelastpickle.com>
Date: Mon, 18 Jul 2011 10:53:44 -0700
Message-ID: 
 <CAAC9M_2fuG_2xbiifJqK6m3C0iyDpMot6AzeS4sDuaDFxSMywQ@mail.gmail.com>
Subject: Re: Data overhead discussion in Cassandra
From: Sameer Farooqui <cassandralabs@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=00151774106430e34104a85baedf

--00151774106430e34104a85baedf
Content-Type: text/plain; charset=ISO-8859-1

Aaron,

That additional 15 bytes of overhead was the missing puzzle piece.

We had RF = 3.

So, now my calculations show that our CF should have a total of about 3.1 TB
of data and the actual figure is 3.3 TB (which might just be some stale
tombstones).

Thanks for the clarification about what else the index file contains, it
helps us justify the additional storage overhead.

- Sameer


On Sun, Jul 17, 2011 at 4:04 PM, aaron morton <aaron@thelastpickle.com>wrote:

> What RF are you using ?
>
> On disk each column has 15 bytes of overhead, plus the column name and the
> column value. So for an 8 byte long and a 8 byte double there will be 16
> bytes of data and 15 bytes of data.
>
> The index file also contains the the row key, the MD5 token (for RP) and
> the row offset for the data file.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 15 Jul 2011, at 07:09, Sameer Farooqui wrote:
>
> > We just set up a demo cluster with Cassandra 0.8.1 with 12 nodes and
> loaded 1.5 TB of data into it. However, the actual space on disk being used
> by data files in Cassandra is 3 TB. We're using a standard column family
> with a million rows (key=string) and 35,040 columns per key. The column name
> is a long and the column value is a double.
> >
> > I was just hoping to understand more about why the data overhead is so
> large. We're not using expiring columns. Even considering indexing and bloom
> filters, it shouldn't have bloated up the data size to 2x the original
> amount. Or should it have?
> >
> > How can we better anticipate the actual data usage on disk in the future?
> >
> > - Sameer
>
>

--00151774106430e34104a85baedf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Aaron,<br><br>That additional 15 bytes of overhead was the missing puzzle p=
iece.<br><br>We had RF =3D 3.<br><br>So, now my calculations show that our =
CF should have a total of about 3.1 TB of data and the actual figure is 3.3=
 TB (which might just be some stale tombstones).<br>
<br>Thanks for the clarification about what else the index file contains, i=
t helps us justify the additional storage overhead. <br><br>- Sameer<br><br=
><br><br><div class=3D"gmail_quote">On Sun, Jul 17, 2011 at 4:04 PM, aaron =
morton <span dir=3D"ltr">&lt;<a href=3D"mailto:aaron@thelastpickle.com">aar=
on@thelastpickle.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">What RF are you using ?<br>
<br>
On disk each column has 15 bytes of overhead, plus the column name and the =
column value. So for an 8 byte long and a 8 byte double there will be 16 by=
tes of data and 15 bytes of data.<br>
<br>
The index file also contains the the row key, the MD5 token (for RP) and th=
e row offset for the data file.<br>
<br>
Cheers<br>
<br>
-----------------<br>
<font color=3D"#888888">Aaron Morton<br>
Freelance Cassandra Developer<br>
@aaronmorton<br>
<a href=3D"http://www.thelastpickle.com" target=3D"_blank">http://www.thela=
stpickle.com</a><br>
</font><div><div></div><div class=3D"h5"><br>
On 15 Jul 2011, at 07:09, Sameer Farooqui wrote:<br>
<br>
&gt; We just set up a demo cluster with Cassandra 0.8.1 with 12 nodes and l=
oaded 1.5 TB of data into it. However, the actual space on disk being used =
by data files in Cassandra is 3 TB. We&#39;re using a standard column famil=
y with a million rows (key=3Dstring) and 35,040 columns per key. The column=
 name is a long and the column value is a double.<br>

&gt;<br>
&gt; I was just hoping to understand more about why the data overhead is so=
 large. We&#39;re not using expiring columns. Even considering indexing and=
 bloom filters, it shouldn&#39;t have bloated up the data size to 2x the or=
iginal amount. Or should it have?<br>

&gt;<br>
&gt; How can we better anticipate the actual data usage on disk in the futu=
re?<br>
&gt;<br>
&gt; - Sameer<br>
<br>
</div></div></blockquote></div><br>

--00151774106430e34104a85baedf--