Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 2227 invoked from network); 1 Sep 2010 08:33:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Sep 2010 08:33:02 -0000 Received: (qmail 40039 invoked by uid 500); 1 Sep 2010 08:33:01 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 39893 invoked by uid 500); 1 Sep 2010 08:32:57 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 39885 invoked by uid 99); 1 Sep 2010 08:32:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Sep 2010 08:32:57 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a40.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Sep 2010 08:32:50 +0000 Received: from homiemail-a40.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a40.g.dreamhost.com (Postfix) with ESMTP id EE24974C06D for ; Wed, 1 Sep 2010 01:32:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; q=dns; s= thelastpickle.com; b=ZWs2flPmhbTYeKejI6i9uGXoWz/5fayRq2Rmq/stgSW jN12EcE7q9ySbg2TO4VCBSpGmpeIYE/6IH2nW9117Az4MsDQmaICouuzqj0YEKsi zKppWovPWCCuMZGEsaixqugVhiLLF/v9GUB9sz504PM66nGFuEZ4NmztdgiMUCpg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h= content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; s= thelastpickle.com; bh=Px0Og8UMrDzMHr7zBqFJny/TMKc=; b=Lx+rTiDvj7 oFqZ6RYzbYxUWlHhJ7trE/5JruoCaUjn5NetMzRelSejj5TZyH7ugBSin3iFgxZ6 cQcZP7+L2faulYZs7KMe1OMBVRGFPPYirhHb0W64JwDr4r/hEHWacs7uz3eYBX9e nVQov6wwW0yOcXN7V9QRkzVSvZqYSWyHY= Received: from [10.0.1.157] (121-73-157-230.cable.telstraclear.net [121.73.157.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a40.g.dreamhost.com (Postfix) with ESMTPSA id 57D7774C069 for ; Wed, 1 Sep 2010 01:32:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: Need help in cassandra data model.. From: aaron morton In-Reply-To: Date: Wed, 1 Sep 2010 20:32:26 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: user@cassandra.apache.org X-Mailer: Apple Mail (2.1081) =46rom what you have described that sounds OK (am assuming there is not = millions of events per transaction). When designing the model consider = all the ways you will want to read the data back and then dernomalize = the data appropriately. Ideally each request for data from cassandra = should be handled by single CF.=20 When storing the time of the event, you could use either a Long as the = seconds since epoch or an ASCII string with the time formatted using the = ISO format.=20 Aaron On 1 Sep 2010, at 19:09, Manikandan R wrote: > Hello Everyone, >=20 > I am doing study on cassandra to make use of it for the below problem = -=20 >=20 > My current system has many components. To complete any = transaction(request), it has to pass through all the components. While = it passes through, there is no clear visibility to know what is = happening behind each component at any given point. >=20 > Trying to create a new component using cassandra, which receives the = status of the transaction(request) from other components for any given = transaction(request) id, so that it can viewed online in real time. >=20 > Here is the model, I have in my mind: >=20 > Transactions: { >=20 > 100: { //transaction id as key >=20 > t1: { //Say, at time t1 >=20 > status: "Received the request. Doing validation"; > mode: "debug"; > }; >=20 > t2 : { // Say, at time t2 > =20 > status: "dropped:1000|absent=3D2000"; > dropped: 1000; > absent: 2000; > mode: "info"; > }; >=20 >=20 >=20 > 101: { //transaction id as key >=20 > t1: { //Say, at time t1 >=20 > status: "Doing External Verification..." > mode: "debug"; > }; >=20 > t2 : { // Say, at time t2 > =20 > status: "valid:2000|invalid:1000"; > valid: 1000; > invalid: 1000; > mode: "info"; > }; > } >=20 > Status can delivered to the users depending on the SLA. Based on the = mode, it can be displayed to users. Users who has access to see detailed = status, can see all the mode's status, where as, user who want to see = only reports, can see the mode with "info".=20 >=20 > Please let me know your thoughts. >=20 > Thanks, > Mani