Re: Materialized Views marked experimental

[Jeff Jirsa]

> On Oct 27, 2017, at 2:23 AM, Gábor Auth  wrote:
> 
> Hi,
> 
>> On Thu, Oct 26, 2017 at 11:10 PM Blake Eggleston  
>> wrote:
>> Following a discussion on dev@, the materialized view feature is being 
>> retroactively classified as experimental, and not recommended for new 
>> production uses. The next patch releases of 3.0, 3.11, and 4.0 will include 
>> CASSANDRA-13959, which will log warnings when materialized views are 
>> created, and introduce a yaml setting that will allow operators to disable 
>> their creation.
> 
> Will the experimental classification later be withdrawn (the issue can be 
> fixable)?
> Will the whole MV feature later be withdrawn (the issue can't be fixable)? :)
> 

The experimental warning will be withdrawn when there’s confidence among 
committers that the feature always does the right thing with your data. 

The algorithm SEEMS safe (with the caveats Blake mentioned), and people DO use 
it in production, we just want you to be aware that we’re not as confident in 
its safety as we are for the more mature database features.

Re: Materialized Views marked experimental

[Gábor Auth]

Hi,

On Thu, Oct 26, 2017 at 11:10 PM Blake Eggleston 
wrote:

> Following a discussion on dev@, the materialized view feature is being
> retroactively classified as experimental, and not recommended for new
> production uses. The next patch releases of 3.0, 3.11, and 4.0 will include
> CASSANDRA-13959, which will log warnings when materialized views are
> created, and introduce a yaml setting that will allow operators to disable
> their creation.
>

Will the experimental classification later be withdrawn (the issue can be
fixable)?
Will the whole MV feature later be withdrawn (the issue can't be fixable)?
:)

Bye,
Gábor Auth

Materialized Views marked experimental

[Blake Eggleston]

Hi user@,

Following a discussion on dev@, the materialized view feature is being 
retroactively classified as experimental, and not recommended for new 
production uses. The next patch releases of 3.0, 3.11, and 4.0 will include 
CASSANDRA-13959, which will log warnings when materialized views are created, 
and introduce a yaml setting that will allow operators to disable their 
creation.

Concerns about MV’s suitability for production are not uncommon, and this just 
formalizes the advice often given to people considering materialized views. 
That is: materialized views have shortcomings that can make them unsuitable for 
the general use case. If you’re not familiar with their shortcomings and 
confident they won’t cause problems for your use case, you shouldn’t use them

The shortcomings I’m referring to are:
* There's no way to determine if a view is out of sync with the base table.
* If you do determine that a view is out of sync, the only way to fix it is to 
drop and rebuild the view.
Even in the happy path, there isn’t an upper bound on how long it will take for 
updates to be reflected in the view.

There is also concern that the materialized view design isn’t known to be 
‘correct’. In other words, it’s a distributed system design that hasn’t been 
extensively modeled and simulated, and there have been no formal proofs about 
it’s properties.

You should be aware that manually denormalizing your tables has these same 
limitations in most cases, so you may not be losing any guarantees by using 
materialized views in your use case. The reason we’re doing this is because 
users expect correctness from features built into a database. It’s not 
unreasonable for users to think that a database feature will more or less “just 
work”, which is not necessarily the case for materialized views. If a feature 
is considered experimental, users are more likely to spend the time 
understanding it’s shortcomings before using it in their application.

Thanks,

Blake

The dev@ thread can be found here: 
https://www.mail-archive.com/dev@cassandra.apache.org/msg11511.html