Howdy, Some Polyglot Persistence(NoSQL) products started support server side scripting, similar to RDBMS store procedure. E.g. Redis Lua scripting.
I wish it is Python when Cassandra has the server side scripting feature. FYI, http://antirez.com/post/250 http://nosql.mypopescu.com/post/19949274021/alchemydb-an-integrated-graphdb-rdbms-kv-store "server side scripting support is an extremely powerful tool. Having processing close to data (i.e. data locality) is a well known advantage, ..., it can open the doors to completely new features." Thanks, Charlie (@mujiang) 一个 木匠 ======= Data Architect Developer http://mujiang.blogspot.com On Sun, Apr 22, 2012 at 9:35 AM, Brian O'Neill <[email protected]> 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/ > -- -- Thanks, Charlie (@mujiang) 一个 木匠 ======= Data Architect Developer http://mujiang.blogspot.com
