> > the default behavioural unsafety we opt for by not writing through the > batch log
We always write to the local batchlog (unless the MV replica is the local node)... Most of the bugs have been around tombstones and ttls AFAIK. On Tue, Oct 3, 2017 at 3:23 PM, Benedict Elliott Smith <_...@belliottsmith.com> wrote: > This link is a helpful segway to another problem with MVs and defaults - > the default behavioural unsafety we opt for by not writing through the > batch log, opening far more windows for data inconsistency than the > algorithm otherwise permits. Without a way to detect or repair these > inconsistencies this seems cavalier as a default, and it's even more > pressing to change in my opinion, however we resolve the experimental > status (I am in favour of marking them experimental also, ftr) > > As the originator of the broad-strokes algorithm, I'd more generally like > to offer my 2c that we do not sufficiently understand the algorithm's > qualities to recommend it in production, or perhaps at all. We had agreed > over IRC that we would model/simulate the algorithm under a multiplicity of > cluster scenarios (by which I mean something more complete than dtests) > before we released, but this unfortunately never materialised. > > The documentation at present also doesn't highlight the problems we *know* > can occur, such as with availability-loss, and the fuzzy-application of > consistency levels with MVs. > > Certainly it may be said that it was harder to achieve this functionality > by application maintainers, but I do think we have a duty of care to fully > understand and explain the new tools we provide, as it may be that we offer > fewer guarantees than many users might be able to readily achieve, and they > don't know this. Even for those users we can offer better guarantees, it > is in my opinion fundamentally a problem to offer a tool we do not fully > understand or fully explain/caveat the behaviour of. > > > On 3 Oct 2017, at 15:02, Jake Luciani <jak...@gmail.com> wrote: > > >> > >> The remaining issues 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. > >> * There are liveness issues with updates being reflected in the view. > >> > > > > I just want to mention that manual de-normalization has all the same > issues > > as the list of above. If you write to multiple tables with batch logs > when > > do you know the data is consistent? > > In fact, manual de-normalization is worse because you can't manually > handle > > updates to existing data due to the lack of synchronization on read > before > > write. > > > > I think a lot of you have lost sight on what MV was intended for, as a > way > > to keep developers from manually maintaining a consistent view of data > > across tables. > > There is still the fundamental problem of managing multiple views of data > > even if you remove the MV feature, you just make it someone else's > problem. > > > > I'll re-post this blog from back when MVs first came out to hopefully > clear > > questions up on the goals of MV. > > > > https://www.datastax.com/dev/blog/understanding-materialized-views > > > > -Jake > > > > > > On Tue, Oct 3, 2017 at 2:50 PM, Aleksey Yeshchenko <alek...@apple.com> > > wrote: > > > >> Indeed. Paulo and Zhao did a lot of good work to make the situation less > >> bad. You did some as well. Even I retouched small parts of it - metadata > >> related. I’m sorry if I came off as disrespectful - I didn’t mean to. > I’ve > >> seen and I appreciate every commit that went into it. > >> > >> It is however my opinion that we started at a very low point, for a > >> variety of reasons, and climbing out of that initial poor state, to the > >> level that power users start having trust in MVs and overcome the > initial > >> deservedly poor impression, will probably take even more work. And > when/if > >> we get there, maybe we won’t need the switch anymore. > >> > >> — > >> AY > >> > >> On 3 October 2017 at 17:00:31, Sylvain Lebresne (sylv...@datastax.com) > >> wrote: > >> > >> You're giving little credit to the hard work that people have put into > >> getting MV in a usable state. > >> > > > > > > > > -- > > http://twitter.com/tjake > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- http://twitter.com/tjake
