cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian ONeill (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-1311) Triggers
Date Sat, 25 Feb 2012 00:53:51 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216192#comment-13216192
] 

Brian ONeill commented on CASSANDRA-1311:
-----------------------------------------

re: more than once processing

Agreed. We have a low write volume right now, which makes it likely that a node can process
all of its log entries within N seconds. We were also more concerned that log entries would
sit in the commit log unprocessed in the event of a node failure.  Thinking about it a little
more, maybe we could have written the hash of the row key as a column and query for log entries
based on the keyspace segment for which the node is repsonsible.

re: passing the row mutation

Also agreed.  In fact, the initial implementation wrote the serialized object, but that seemed
heavy in the event that large blobs are being written. (duplicating the data in the commit
log)  Additionally, we wanted to discourage developers from acting on the contents of the
row mutation (e.g. updating an index or view), because the datat contained in the mutation
may be out of date. (do to the fact that the mutation could have been received out of order)
 In the second refactoring, we wrote just wrote the column names that were mutated.  That
seemed sufficient.  In its current state, even that is configurable.  We just write the keyspace,
column family, row and operation that was performed.  That way, the commit log is light weight.
 It is really just a notificaiton that something changed.  The rest is up to the trigger.

                
> Triggers
> --------
>
>                 Key: CASSANDRA-1311
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Maxim Grinev
>             Fix For: 1.2
>
>         Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt,
ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt,
trunk-984391-update2.txt
>
>
> Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous
execution of application code at database side. For example to support indexes and materialized
views, online analytics, push-based data propagation.
> Please find the motivation, triggers description and list of applications:
> http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
> An example of using triggers for indexing:
> http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
> Implementation details are attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message