We're just short of 98 tickets on the component since it's original merge so at least *some* work has been done to stabilize them. Not to say I'm endorsing running them at massive scale today without knowing what you're doing, to be clear. They are perhaps our largest loaded gun of a feature of self-foot-shooting atm. Zhao did a bunch of work on them internally and we've backported much of that to OSS; I've pinged him to chime in here.
The "data is orphaned in your view when you lose all base replicas" issue is more or less "unsolvable", since a scan of a view to confirm data in the base table is so slow you're talking weeks to process and it totally trashes your page cache. I think Paulo landed on a "you have to rebuild the view if you lose all base data" reality. There's also, I believe, the unresolved issue of modeling how much data a base table with one to many views will end up taking up in its final form when denormalized. This could be vastly improved with something like an "EXPLAIN ANALYZE" for a table with views, if you'll excuse the mapping, to show "N bytes in base will become M with base + views" or something. Last but definitely not least in dumping the state in my head about this, there's a bunch of potential for guardrailing people away from self-harm with MV's if we decide to go the route of guardrails (link: https://cwiki.apache.org/confluence/display/CASSANDRA/%28DRAFT%29+-+CEP-3%3A+Guardrails ). So from my PoV, I'm against us just voting to deprecate and remove without going into more depth into the current state of things and what options are on the table, since people will continue to build MV's at the client level which, in theory, should have worse correctness and performance characteristics than having a clean and well stabilized implementation in the coordinator. Having them flagged as experimental for now as we stabilize 4.0 and get things out the door *seems* sufficient to me, but if people are widely using these out in the wild and ignoring that status and the corresponding warning, maybe we consider raising the volume on that warning for 4.0 while we figure this out. Just my .02. ~Josh On Tue, Jun 30, 2020 at 4:22 PM Dinesh Joshi <djo...@apache.org> wrote: > > On Jun 30, 2020, at 12:43 PM, Jon Haddad <j...@jonhaddad.com> wrote: > > > > As we move forward with the 4.0 release, we should consider this an > > opportunity to deprecate materialized views, and remove them in 5.0. We > > should take this opportunity to learn from the mistake and raise the bar > > for new features to undergo a much more thorough run the wringer before > > merging. > > I'm in favor of marking them as deprecated and removing them in 5.0. If > someone steps up and can fix them in 5.0, then we always have the option of > accepting the fix. > > Dinesh > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
