cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maxim Grinev (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1311) Support (asynchronous) triggers
Date Fri, 25 Feb 2011 17:51:27 GMT

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

Maxim Grinev commented on CASSANDRA-1311:
-----------------------------------------

Jonathan, are we right that you are mainly concerned about the inconsistency problem we were
discussing earlier?

To repeat, the problem was that if a write has not been acknowledged, it may still have succeeded
in the base columnfamily (Table.apply) but the trigger is stored durably (TriggerSlave.storeDanglingTrigger).
It is because trigger execution is not part of log replay. So we can end up with data that
never had the trigger fire.

As Stu said, using entity groups to solve this problem is suboptimal. We want to propose an
improvement of our approach that also solves this problem but does not introduce the restrictions
of entity groups. 

Our solution is to make the storage of "dangling" trigger at replicas also part of log replay.
Whenever a replica (slave) node receives a write request, it will durably log that it has
to fire a trigger in case of a failure of the update coordinator (master). In case this slave
node fails, it will come back up replaying the logs, installing any data item, and also firing
triggers.

Once again, our point is to avoid entity group whenever possible for the following two reasons.
(1) Entity groups are restrictive because they require co-location of data. This is hard to
achieve in practice and not all application can be implemented this. For example, it is not
possible to implement Twitter as it would require to co-locate users with their followers
ending up with a single, big entity group. (2) Even in case when you can use entity groups,
you usually need to update redundant data stored in other entity groups as well. In this case,
triggers may be used to keep redundant data consistent across entity groups.

> Support (asynchronous) triggers
> -------------------------------
>
>                 Key: CASSANDRA-1311
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Contrib
>            Reporter: Maxim Grinev
>             Fix For: 0.8
>
>         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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message