cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Broecheler (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-10546) Custom MV support
Date Fri, 16 Oct 2015 21:38:05 GMT
Matthias Broecheler created CASSANDRA-10546:

             Summary: Custom MV support
                 Key: CASSANDRA-10546
             Project: Cassandra
          Issue Type: New Feature
            Reporter: Matthias Broecheler

The MV implementation should be generalized to allow for custom materialized view implementations.
Like with MV, the logic would be triggered by a mutation to some base table on which the custom
MV is registered. A custom MV would allow for custom logic to determine the "derived" mutations
that need to be applied as a result of the base table mutation. It would then ensure that
those derived mutations are applied (to other tables) as the current MV implementation does.

Note, that a custom MV implementation is responsible for ensuring that any tables that derived
mutations are written into exist. As such, a custom MV implementation has an initialization
logic which can create those tables upon registration if needed. There should be no limit
on what table a custom MV can write derived records to (even existing ones).

(Note, that this example is somewhat construed for simplicity)

We have a table in which we track user visits to certain properties with timestamp:
  userId bigint,
  visitAt timestamp,
  property varchar,
  PRIMARY KEY (userId, visitAt)

Every time a user visits a property, a record gets added to this table. Records frequently
come in out-of-order.
At the same time, we would like to know who is currently visiting a particular property (with
their last entry time).
For that, we create a custom MV registered against the {{visits}} table which upon registration
creates the following table:
CREATE TABLE currentlyVisiting (
  property varchar,
  userId bigint,
  enteredOn timestamp,
  PRIMARY KEY (property, userId)

Now, when a record (u,v,p) gets inserted into the {{visits}} table the custom MV logic gets
# It reads the most recent visit record for user u: (u,v',p').
# If no such record exists, it emits (p,u,v) targeting table {{currentlyVisiting}} as a derived
record to be persisted.
# If such a record exists and v'>=v then it emits nothing. But if v'<v it emits records
(p',u,v') to be deleted and (p,u,v) to be added to table {{currentlyVisiting}}.

The MV framework ensures that the emitted records get persisted correctly.

This message was sent by Atlassian JIRA

View raw message