Have you been bothered by the way Cassandra organized data, and that you need to frequently deduplicate data just to modify or find them at once? Not to bother updating them using the infamous consistency level of QUORUM, which may yield you Cassandra in less that consistent state.
MATERIALIZED VIEWS
Materialized views are just another name for a table, that’s automatically compiled and kept in sync with a single other table. It primary keys may differ, but only by one.
A downside: a materialized view can be constructed only from one table, so no fancy joins for you right now.
A short primer
A MATERIALIZED VIEW is the same as a normal Cassandra table, only that is is maintained in the background by Cassandra. It can contain it’s own compaction strategies and the folks. It also cannot be directly modified.
The downsides
- MATERIALIZED VIEWS don’t appear in https://cassandra.tools/cassandra-web tool, so you just might forget to deploy them into production (happened to me once).
- They may take a while to build, but in my experience running SSD drives the process is rather quick.
- Tables that serve as source of truth for MATERIALIZED VIEWS cannot undergo incremental repairs.
Upsides
Ever needed to use a quorum_batch to change an information? Well, these times are long past gone.
MATERIALIZED VIEWS appear however in JetBrain’s DataGrip.
A word of caution! Since this is an experimental feature, you’ll need to enable it for each of your Cassandra nodes in your cassandra.yaml file with the following:
enable_materialized_views: trueFrom my perspective, they’ve been stable and therefore I have no contraindications to running them in production. Of course, if you fancy your incremental repairs, you may be reluctant to go with them, and I give you my full blessing to stick with your quorum batches.
