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 markxr@gmail.com designates
 209.85.218.222 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=VSoZ5LO+z8+J/aAFbXQ4PsPhYdlnt6hIxcuG3cdnhw2Jgf9MYAf7/PE3XbzmIu7Rv8
         +7bcdh0aovLVkFB9EARAR4Xrjnu1l9nKhAAncwWzbz0EzNql5QTly89ev4Cbo6PWIEMe
         1IxVjBJxQhZoTuP5rn26Dp75uUqdYanl4jAbA=
MIME-Version: 1.0
In-Reply-To: <z2w8f9ac4a91004110059q19fa0425s1fa0b2aa64b5a30f@mail.gmail.com>
References: <z2w8f9ac4a91004110059q19fa0425s1fa0b2aa64b5a30f@mail.gmail.com>
Date: Sun, 11 Apr 2010 10:28:42 +0000
Message-ID: <g2off1a07b81004110328y38b7335dl81413d808cca62fd@mail.gmail.com>
Subject: Re: concept to query cassandra
From: Mark Robson <markxr@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=0016e6d99ca113cbca0483f37e2c

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

On 11 April 2010 07:59, Lucifer Dignified <vineetdaniel@gmail.com> wrote:

> For a very simple query wherin we need to check username and password  I
> think keeping incremental numeric id as key and keeping the name and value
> same in the column family should work.
>

It is highly unlikely that your application has enough usernames/passwords
that you need Cassandra to store them in.

If you have < 1Bn rows, I really think you should reconsider whether
Cassandra is the best solution.

Remember that you pay for Cassandra's high availability / scalability
features with a lack of these other features (secondary indexes, joins,
query optimiser) - be sure it's worth it.

There are workarounds, but they essentially involve rewriting your RDBMS to
use Cassandra as a back-end. This is not a simple task, nor one which should
be necessary.

Remember that if you have SOME big data, and some small data, you don't need
to keep it all in the same place. A common use-case is to keep your big
stuff (heavy write workloads etc) in Cassandra and the others in a more
familiar database.

Mark

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

<div class=3D"gmail_quote">On 11 April 2010 07:59, Lucifer Dignified <span =
dir=3D"ltr">&lt;<a href=3D"mailto:vineetdaniel@gmail.com">vineetdaniel@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"b=
order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin=
g-left: 1ex;">
For a very simple query wherin we need to check username and password=A0 I =
think keeping incremental numeric id as key and keeping the
name and value same in the column family should work.<br></blockquote><div>=
<br>It is highly unlikely that your application has enough usernames/passwo=
rds that you need Cassandra to store them in.<br><br>If you have &lt; 1Bn r=
ows, I really think you should reconsider whether Cassandra is the best sol=
ution.<br>
<br>Remember that you pay for Cassandra&#39;s high availability / scalabili=
ty features with a lack of these other features (secondary indexes, joins, =
query optimiser) - be sure it&#39;s worth it.<br><br>There are workarounds,=
 but they essentially involve rewriting your RDBMS to use Cassandra as a ba=
ck-end. This is not a simple task, nor one which should be necessary.<br>
<br>Remember that if you have SOME big data, and some small data, you don&#=
39;t need to keep it all in the same place. A common use-case is to keep yo=
ur big stuff (heavy write workloads etc) in Cassandra and the others in a m=
ore familiar database.<br>
<br>Mark<br></div></div>

--0016e6d99ca113cbca0483f37e2c--