concept to query cassandra

[Lucifer Dignified <vi...@gmail.com>]

Hi

I've been thinking of using cassandra for our existing application, which
has a very complex RDBMS schema as of now, and we need to make a lot of
queries using joins and where.
Whereas we can eliminate joins by using duplicate entries, its still hard to
query cassandra. I have thought of a way of doing it. I dont know how good
it. My idea is as :

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.

Example :
User1 has password as 123456

Cassandra structure :

1 as key
           user1 - column name
           value - user1
           123456 - column name
            value - 123456

I m thinking of doing it this way for my applicaton, this way i can run
different sorts of queries too, using get_slice and other functions. Any
feedback on this is welcome.

Join High Availability group on Facebook (effort to bring all HA force
together) :
http://www.facebook.com/groups/edit.php?edit_members&gid=116428271708033#!/group.php?gid=116428271708033

Re: concept to query cassandra

[Lucifer Dignified <vi...@gmail.com>]

It was just an example to showcase how i want to implement it, and I have
even added that this entierly depends upon what you want and what the
scenario is, i'm thinking of using this for articles that we are storing,
and the number is big. thinking of making each values as column name itself.

Once I am done with its intial designing I'll share with you guys. If at any
moment i feel that it won't work, will update in that case also.

On Sun, Apr 11, 2010 at 3:58 PM, Mark Robson <ma...@gmail.com> wrote:

> On 11 April 2010 07:59, Lucifer Dignified <vi...@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
>

Re: concept to query cassandra

[Mark Robson <ma...@gmail.com>]

On 11 April 2010 07:59, Lucifer Dignified <vi...@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