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 tyler@datastax.com designates
 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BANLkTi=woF0wOJuwC59cm5EKuMGnCpJmpQ@mail.gmail.com>
References: <BANLkTimDvu=z3Wh00b-LxYNU+qXu49kexA@mail.gmail.com>
	<BANLkTi==cwCZ95gXzy7uZ+p59vm8sC3tzA@mail.gmail.com>
	<BANLkTinqGPvzeKyX5EpMvGW5gHDjxvy4mQ@mail.gmail.com>
	<BANLkTinFQfACgC-WgCnU3jjuCKqBZhBQBg@mail.gmail.com>
	<BANLkTik=xDyk3TB1-Bkmy-t0qLFSCB3LVQ@mail.gmail.com>
	<BANLkTinMNBXeEzonws2FWVNeWXX9odAcUA@mail.gmail.com>
	<BANLkTima1ESv_MSxokgWBe-XkueSQjO6PQ@mail.gmail.com>
	<BANLkTimaSEWyhthzAuHrenvqAn4tp-qp7w@mail.gmail.com>
	<BANLkTi=ip0Qd1xnjN1Sn_SF5uA=dJ3p6WQ@mail.gmail.com>
	<BANLkTimY=L2+pK5gdZ0SEhvsbuGtfAYWOw@mail.gmail.com>
	<BANLkTi=Ae4Be1mNmYUgoEOmj0E39fzmBtw@mail.gmail.com>
	<BANLkTimTLS+AfbC-r3dsNu5vmaQtpKYWSw@mail.gmail.com>
	<BANLkTi=woF0wOJuwC59cm5EKuMGnCpJmpQ@mail.gmail.com>
Date: Mon, 2 May 2011 12:12:56 -0500
Message-ID: <BANLkTi=4=c3fyHN6PsTOYqdEr_cZTBCsAw@mail.gmail.com>
Subject: Re: Combining all CFs into one big one
From: Tyler Hobbs <tyler@datastax.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=0016e644ccd47e35f604a24e22b0

--0016e644ccd47e35f604a24e22b0
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 2, 2011 at 12:06 PM, David Boxenhorn <david@taotown.com> wrote:

> I guess I'm still feeling fuzzy on this because my actual use-case isn't so
> black-and-white. I don't have any CFs that are accessed purely, or even
> mostly, in once-through batch mode. What I have is CFs with more and less
> data, and CFs that are accessed more and less frequently.
>

I figured that was the case; the black-and-white CFs just make easier
examples.  Back at the beginning of the thread, I recommend merging CFs that
have similar data "shapes" and highly correlated access patterns.  For
example, if you had two CFs, "user profile" and "group profile", that both
had fixed-length rows and tended to both be read for some type of
operations, those would be a good candidate for merging.  Just take the
ideas from the black-and-white examples and apply them in a more nuanced
way.

-- 
Tyler Hobbs
Software Engineer, DataStax <http://datastax.com/>
Maintainer of the pycassa <http://github.com/pycassa/pycassa> Cassandra
Python client library

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

<div class=3D"gmail_quote">On Mon, May 2, 2011 at 12:06 PM, David Boxenhorn=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:david@taotown.com">david@taotown.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir=3D"ltr">I guess I&#39;m still feeling fuzzy on this because my act=
ual use-case isn&#39;t so black-and-white. I don&#39;t have any CFs that ar=
e accessed purely, or even mostly, in once-through batch mode. What I have =
is CFs with more and less data, and CFs that are accessed more and less fre=
quently. <br>
</div></blockquote></div><br>I figured that was the case; the black-and-whi=
te CFs just make easier=20
examples.=A0 Back at the beginning of the thread, I recommend merging CFs=
=20
that have similar data &quot;shapes&quot; and highly correlated access patt=
erns.=A0=20
For example, if you had two CFs, &quot;user profile&quot; and &quot;group p=
rofile&quot;,=20
that both had fixed-length rows and tended to both be read for some type
 of operations, those would be a good candidate for merging.=A0 Just take t=
he ideas from the black-and-white examples and apply them in a more nuanced=
 way.<br><br>-- <br><font color=3D"#888888">Tyler Hobbs<span></span><br>
Software Engineer, <a href=3D"http://datastax.com/" target=3D"_blank">DataS=
tax</a><br>Maintainer of the <a href=3D"http://github.com/pycassa/pycassa" =
target=3D"_blank">pycassa</a> Cassandra Python client library<br></font><br=
>

--0016e644ccd47e35f604a24e22b0--