> 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.
I agree with Josh here. Multiple people have put in effort to improve the stability of MV’s since they were first put into the code base and the reasons for having them be in the DB have not changed. Building MV like tables at the client level is actually harder to get right than doing it in the server. -Jeremiah > On Jun 30, 2020, at 3:45 PM, Joshua McKenzie <jmcken...@apache.org> wrote: > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
