incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Morton <aa...@thelastpickle.com>
Subject Re: Design Question
Date Mon, 08 Nov 2010 19:48:29 GMT
FWIW I would recommend first trying to solve the issue in your application rather than with
Cages or Zoo Keeper. Although I do not have experience with Cages or Zoo Keeper, it's another
major server component in your stack.

If you really do have a queue and multiple simultaneous readers consider using something like
Rabbit MQ http://www.rabbitmq.com/ . Or try something like Redis http://code.google.com/p/redis/ or
Gear Man http://gearman.org/ to get a quick prototype going.

Hope that helps. 
Aaron

On 08 Nov, 2010,at 02:05 PM, Mubarak Seyed <mubarak.seyed@gmail.com> wrote:

Hi All,

Can someone please validate and recommend a solution for the given design problem?

Problem statement: Need to de-queue data from Cassandra (from Standard ColumnFamily) using
a job but multiple instances of a job can run simultaneously (kinda multiple threads), trying
to access a same row but need to make sure that only one instance of a job (thread) can access
a row, meaning if job A is accessing Row #1, then job B can't access Row #1.

Possible solutions:

Solution #1: Using Cages (and ZooKeeper) to make sure that one only job at a time can access
a row in CF. How do we make sure that Cages (transaction coordinator using ZooKeeper) is not
a Single Point of Failure? What is the performance impact on write/read on nodes? There
is some blog on distributed concurrent queue at http://www.cloudera.com/blog/2009/05/building-a-distributed-concurrent-queue-with-apache-zookeeper/

Solution #2: Using some home-grown approach to store/maintain who is accessing what, meaning
which job is accessing which row.

Are there any other solutions to the above problem?  

Can someone please help me on validate the design?

-- 
Thanks,
Mubarak Seyed.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message