From user-return-25689-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Sun Apr 22 16:36:30 2012 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EFACE91DF for ; Sun, 22 Apr 2012 16:36:30 +0000 (UTC) Received: (qmail 30126 invoked by uid 500); 22 Apr 2012 16:36:28 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 30055 invoked by uid 500); 22 Apr 2012 16:36:28 -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 30043 invoked by uid 99); 22 Apr 2012 16:36:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Apr 2012 16:36:28 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of boneill42@gmail.com designates 209.85.160.44 as permitted sender) Received: from [209.85.160.44] (HELO mail-pb0-f44.google.com) (209.85.160.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Apr 2012 16:36:21 +0000 Received: by pbbrp16 with SMTP id rp16so2963623pbb.31 for ; Sun, 22 Apr 2012 09:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=F5tQV1InrKKAU+ahOULcS2uax9/p7LlVC56mmku+Hto=; b=WbV1dX80YhpAA3LGIWa61iRuVzgsmVtGRI0lEGjDNy69M4y4nz7aKb73kwbSt+z6T3 DyN7N+Lr9rLJ95ZMeg6b8suAwcXv+BBUEqr7yFrWQQBFxwZtsytSTgxrrAJ7sozHBl+J 2TyZcJS4iNZ5ntwq87RfyjJbl9Y3oxB0D2ae7qXp7K1yQu7+suo3ukYVF+XkLbuhvSx+ 6EY9IHAmD0kjtRvlvtxt6xgw7g1BXX0Lv9Bi0NzJa5JuhG6jpT2DVhZuk7cUHISXwOgq wJYiOKtn2tRhjAdQ2Ar7qdK2eK0bH6i3lMuupif+t63xLjmTycyB+Un09kqji74vA7oG XDKA== Received: by 10.68.226.35 with SMTP id rp3mr29205982pbc.44.1335112560415; Sun, 22 Apr 2012 09:36:00 -0700 (PDT) Received: from [192.168.0.102] (c-68-63-149-124.hsd1.pa.comcast.net. [68.63.149.124]) by mx.google.com with ESMTPS id p4sm11799656pbp.13.2012.04.22.09.35.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 09:35:59 -0700 (PDT) Subject: Re: Server Side Logic/Script - Triggers / StoreProc Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-323069414 From: Brian O'Neill In-Reply-To: Date: Sun, 22 Apr 2012 12:35:54 -0400 Cc: Cassandra Dev List Message-Id: <3FFCCFCC-5394-4919-8A0B-D5302789B700@gmail.com> References: To: user@cassandra.apache.org X-Mailer: Apple Mail (2.1084) --Apple-Mail-18-323069414 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Praveen, We are certainly interested. To get things moving we implemented an = add-on for Cassandra to demonstrate the viability (using AOP): https://github.com/hmsonline/cassandra-triggers Right now the implementation executes triggers asynchronously, allowing = you to implement a java interface and plugin your own java class that = will get called for every insert. Per the discussion on 1311, we intend to extend our proof of concept to = be able to invoke scripts as well. (minimally we'll enable javascript, = but we'll probably allow for ruby and groovy as well) -brian On Apr 22, 2012, at 12:23 PM, Praveen Baratam wrote: > I found that Triggers are coming in Cassandra 1.2 = (https://issues.apache.org/jira/browse/CASSANDRA-1311) but no mention of = any StoreProc like pattern. >=20 > I know this has been discussed so many times but never met with any = initiative. Even Groovy was staged out of the trunk. >=20 > Cassandra is great for logging and as such will be infinitely more = useful if some logic can be pushed into the Cassandra cluster nearer to = the location of Data to generate a materialized view useful for = applications. >=20 > Server Side Scripts/Routines in Distributed Databases could soon prove = to be the differentiating factor. >=20 > Let me reiterate things with a use case. >=20 > In our application we store time series data in wide rows with TTL set = on each point to prevent data from growing beyond acceptable limits. = Still the data size can be a limiting factor to move all of it from the = cluster node to the querying node and then to the application via thrift = for processing and presentation. >=20 > Ideally we should process the data on the residing node and pass only = the materialized view of the data upstream. This should be trivial if = Cassandra implements some sort of server side scripting and CQL = semantics to call it. >=20 > Is anybody else interested in a similar feature? Is it being worked = on? Are there any alternative strategies to this problem? >=20 > Praveen >=20 >=20 --=20 Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://weblogs.java.net/blog/boneill42/ blog: http://brianoneill.blogspot.com/ --Apple-Mail-18-323069414 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://github.co= m/hmsonline/cassandra-triggers

Right now = the implementation executes triggers asynchronously, allowing you to = implement a java interface and plugin your own java class that will get = called for every insert.

Per the discussion on = 1311, we intend to extend our proof of concept to be able to invoke = scripts as well.  (minimally we'll enable javascript, but we'll = probably allow for ruby and groovy as = well)

-brian

On Apr 22, = 2012, at 12:23 PM, Praveen Baratam wrote:

I found = that Triggers are coming in Cassandra 1.2 (https://issu= es.apache.org/jira/browse/CASSANDRA-1311) but no mention of any = StoreProc like pattern.

I know this has been discussed so many times but never = met with any initiative. Even Groovy was staged out of the = trunk.

Cassandra is great for logging and as = such will be infinitely more useful if some logic can be pushed into the = Cassandra cluster nearer to the location of Data to generate a = materialized view useful for applications.

Server Side Scripts/Routines in Distributed = Databases could soon prove to be the differentiating = factor.

Let me reiterate things with a use = case.

In our application we store time series = data in wide rows with TTL set on each point to prevent data from = growing beyond acceptable limits. Still the data size can be a limiting = factor to move all of it from the cluster node to the querying node and = then to the application via thrift for processing and = presentation.

Ideally we should process the data on the residing = node and pass only the materialized view of the data upstream. This = should be trivial if Cassandra implements some sort of server side = scripting and CQL semantics to call it.

Is anybody else interested in a similar feature? Is = it being worked on? Are there any alternative strategies to this = problem?

Praveen



= --Apple-Mail-18-323069414--