Matthias Broecheler created CASSANDRA-10546:
-----------------------------------------------
Summary: Custom MV support
Key: CASSANDRA-10546
URL: https://issues.apache.org/jira/browse/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).
Example:
(Note, that this example is somewhat construed for simplicity)
We have a table in which we track user visits to certain properties with
timestamp:
{code}
CREATE TABLE visits (
userId bigint,
visitAt timestamp,
property varchar,
PRIMARY KEY (userId, visitAt)
);
{code}
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:
{code}
CREATE TABLE currentlyVisiting (
property varchar,
userId bigint,
enteredOn timestamp,
PRIMARY KEY (property, userId)
);
{code}
Now, when a record (u,v,p) gets inserted into the {{visits}} table the custom
MV logic gets invoked:
# 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
(v6.3.4#6332)
