Materialized views

While we were modeling our follow relationships, we noted that different access patterns required us to store the same data in multiple tables with different schema. To avoid this denormalization, we created a secondary index on one of the columns. But adding a secondary index on a non-partition key column has a performance impact on read latency. This is especially the case when the column on which the index was created has a high cardinality. Thus, secondary indexes should be used in cases of low cardinality columns or you specify the partition key as well within your queries so the queries don't scale across multiple partitions. To avoid client-side denormalization and the use of secondary indexes for high cardinality columns, materialized views were introduced in Cassandra 3.0. Materialized views handle server-side denormalization ensuring eventual consistency between the base and view...