Out of interest some questions… When writing through triggers how do you handle the CL guarantee ? Is the CL level checked once at the start or checked for each embedded code invocation ?
Do you still guarantee the (non counter) writes as idempotent ? i.e. do the triggers need to be deterministic ? Can clients retry operations that timed out ? Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 23/04/2012, at 5:13 AM, Colin Clark wrote: > In my opinion, triggers/stored procedures are an absolute requirement for any > distributed database. > > We've been using stored procedures in Cassandra now for a while, we've made > modifications such that we don't really write directly anymore but pass > everything through either a default stored procedures (which is just what was > there before) or a dynamically loaded piece of java. > > These stored procedures can call other dynamically loaded pieces of java as > well - we don't have any plans to implement any scripting capabilities. We > can also 'select' from procedures. > > The idea of downloading data from a distributed data base for processing > flies in the face of what nosql and bigdata is all about - you've got to do > it in the db. > > On Apr 22, 2012, at 11:35 AM, Brian O'Neill wrote: > >> 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. >>> >>> 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 >>> >>> >> >> -- >> 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/ >> >
