While working on modelling a schema in Cassandra I encountered the concept of Materialized Views (MV). MVs are basically a view of another table. So any CRUD operations performed on the base table are automatically persisted to the MV. You alter/add the order of primary keys on the MV. Straight away I could see advantages of this. Queries that only differ if the search criteria could make use of MVs. I could let Cassandra manage the updating of the MV instead of me having to manage multiple views.
I was ready to get started. Then, this message appeared after creating a MV:
According to Cassandra, MVs are experimental and are not recommended for production use. None of the literature I read had mentioned this. I decided to delve deeper.
It turns out there have been issues with MVs. The biggest issue being the MV not keeping in sync with the base table. This seems to occur when creating a MV with a key that is not a key of the base table. Cassandra does not offer any mechanism for checking the integrity between the base table and any MVs. So unless you do this manually, you will be oblivious to any discrepancies. If you do find any discrepancies, the only way to fix them is to drop and recreate the MV. This is not ideal. The consensus from the Cassandra community was to add the MV warning after each creation. Without the warning, it was felt that users would expect MVs to be flawless (as I did!). The warning was added to Cassandra version’s 3.0.16, 3.11.2, and 4.0.
There are recommendations to continue using MVs but to implement your own integrity checks. I don’t see this as a worthy trade-off. The overhead of this is probably the equivalent of just creating another table. Personally, I would prefer to be managing my own table, instead of working with this risk. My conclusion is to pay heed to the warning. So for now, we won’t be using MVs in prodution.
- Cassandra The Definitive Guide, 2nd Edition – Jeff Carpenter & Eben Hewitt
- Apache Cassandra Materialized Views Open Jira Issues