Managing Indexes in Cassandra using Async Triggers

So yesterday we spoke about an extension to Cassandra that provides asynchronous triggers. Now we will see a use case in action, managing a secondary index with triggers. In this post, Maxim Grinev and Martin Hentschel are at it again, they describe the use case here:

Cassandra does not support secondary indexes at first, but storing redundant data (in a different layout) will give you the same effect. The main drawback is that your application (the code that writes to the DB) needs to take care of managing the index. Every time you write to the DB, you also need to maintain your index.

So by using the asynchronous triggers you can maintain the secondary index without the performance impact.

Check it out: Managing Indexes in Cassandra using Async Triggers

Follow Up: Cassandra is planning native support for secondary indexes in Cassandra. Here is the JIRA (CASSANDRA-749) full of the discussion among the committers.

Extending Cassandra with Async Triggers

Maxim Grinev and Martin Hentschel have written about a extension they have written for Cassandra, asynchronous triggers. Specifically a trigger in Cassandra is:

Like traditional database triggers, Cassandra Async trigger is a procedure that is automatically executed by the database in response to certain events on a particular database object (e.g. table or view). The distinguishing feature of Async trigger is that the database responds to the client on successful update execution without waiting for triggers to be executed, thus reducing response latency.

What are the attributes of these triggers:

• "After" triggers - A trigger is executed after the update operation that fires the trigger and can see the results of the update
• Trigger procedures are implemented in Java
• Cassandra Async triggers are mutation-level triggers. A trigger is executed for each mutation issued to the column family.
• Cassandra Async triggers are asynchronous. The database acknowledges update execution to the client after the update is executed and the fired triggers are submitted for execution. Actual execution of fired triggers happens after the acknowledgement to the client. It allows saving latency but leads to eventual consistency of data.
• Guarantees triggers to be executed at least once

We will see in a post tomorrow about what you can do with asynchronous triggers.

Read more: Extending Cassandra with Async Triggers