cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "WritePathForUsers" by MichaelEdge
Date Wed, 02 Dec 2015 06:29:44 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "WritePathForUsers" page has been changed by MichaelEdge:
https://wiki.apache.org/cassandra/WritePathForUsers?action=diff&rev1=33&rev2=34

  === If write request modifies materialized view ===
  Keeping a materialized view in sync with its base table adds more complexity to the write
path and also incurs performance overheads on the replica node in the form of read-before-write,
locks and batch logs.
   1. The replica node acquires a lock on the partition, to ensure that write requests are
serialised and applied to base table and materialized views in order.
-  1. The replica node reads the partition data and constructs the set of deltas to be applied
to the materialized view. One insert/update/delete to the base table may result in many inserts/updates/deletes
to the associated materialized view.
+  1. The replica node reads the partition data and constructs the set of deltas to be applied
to the materialized view. One insert/update/delete to the base table may result in one or
more inserts/updates/deletes in the associated materialized view.
   1. Write data to the Commit Log. 
   1. Create batch log containing updates to the materialized view. The batch log ensures
the set of updates to the materialized view is atomic, and is part of the mechanism that ensures
base table and materialized view are kept consistent. 
   1. Store the batch log containing the materialized view updates on the local replica node.
-  1. Send materialized view updates asynchronously to the materialized view replica (note,
the materialized view could be stored on the same or a different replica node to the base
table).
+  1. Send materialized view updates asynchronously to the materialized view replica (note,
the materialized view partition could be stored on the same or a different replica node to
the base table).
   1. Write data to the MemTable.
   1. The materialized view replica node will apply the update and return an acknowledgement
to the base table replica node.
   1. The same process takes place on each replica node that stores the data for the partition
key.

Mime
View raw message