The point with NoSQL is flexibility and RDBMS is structure and guarantees. Both patterns IMHO do overlap. But they do have different USPs.
On Mon, Apr 30, 2012 at 3:51 AM, Maxim Potekhin <[email protected]> wrote: > About a year ago I started getting a strange feeling that > the noSQL community is busy re-creating RDBMS in minute detail. > > Why did we bother in the first place? > > Maxim > > > > On 4/27/2012 6:49 PM, Data Craftsman wrote: > > 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/ > >> > > > > > >
