For the record, in case I was unclear, it was never my intention to suggest that we shouldn't warn about MVs: I would agree that we still should and I'm happy that we do. I would also agree that the remaining caveats and limitations should be more clearly documented.
But, I kind of got the feeling that people were trying to justify taking what I consider somewhat drastic measures (disabling MVs by default _in a patch release_) by piling on on how bad MV were and how impossible it was for anyone ever to use them without dying of a horrible death. This, to me, felt a bit unfair to the hard work that has gone into fixing the more blatant problems. Tl;dr, MVs are certainly not perfect (spoiler alert: they probably will never be) but they are now imo in a state where some users can use them productively, so OK to warn about their remaining problems/limitations, but not ok for me to risk breaking existing user in a patch release. On Wed, Oct 4, 2017 at 3:31 AM, Benedict Elliott Smith <_...@belliottsmith.com> wrote: > So, I'm of the opinion there's a difference between users misusing a well > understood feature whose shortcomings are widely discussed in the community, > and providing a feature we don't fully understand, have not fully documented > the caveats of, let alone discovered all the problems with nor had that > knowledge percolate fully into the wider community. > > I also think there's a huge difference between users shooting themselves in > the foot, and us shooting them in the foot. > > There's a degree of trust - undeserved - that goes with being a database. > People assume you're smarter than them, and that it Just Works. Given this, > and that squandering this trust as a bad thing, I personally believe it is > better to offer the feature as experimental until we iron out all of the > problems, fully understand it, and have a wider community knowledge base > around it. > > We can still encourage users that can tolerate problems to use it, but we > won't be giving any false assurances to those that don't. Doesn't that seem > like a win-win? > > > >> On 3 Oct 2017, at 21:07, Jeremiah D Jordan <jeremiah.jor...@gmail.com> wrote: >> >> So for some perspective here, how do users who do not get the guarantees of >> MV’s implement this on their own? They used logged batches. >> >> Pseudo CQL here, but you should get the picture: >> >> If they don’t ever update data, they do it like so, and it is pretty safe: >> BEGIN BATCH >> INSERT tablea blah >> INSERT tableb blahview >> END BATCH >> >> If they do update data, they likely do it like so, and get it wrong in the >> face of concurrency: >> SELECT * from tablea WHERE blah; >> >> BEGIN BATCH >> INSERT tablea blah >> INSERT tableb blahview >> DELETE tableb oldblahview >> END BATCH >> >> A sophisticated user that understands the concurrency issues may well try to >> implement it like so: >> >> SELECT key, col1, col2 FROM tablea WHERE key=blah; >> >> BEGIN BATCH >> UPDATE tablea col1=new1, col2=new2 WHERE key=blah IF col1=old1 and col2=old2 >> UPDATE tableb viewc1=new2, viewc2=blah WHERE key=new1 >> DELETE tableb WHERE key=old1 >> END BATCH >> >> And it wouldn’t work because you can only use LWT in a BATCH if all updates >> have the same partition key value, and the whole point of a view most of the >> time is that it doesn't (and there are other issues with this, like most >> likely needing to use uuid’s or something else to distinguish between >> concurrent updates, that are not realized until it is too late). >> >> A user who does not dig in and understand how MV’s work, most likely also >> does not dig in to understand the trade offs and draw backs of logged >> batches to multiple tables across different partition keys. Or even >> necessarily of read before writes, and concurrent updates and the races >> inherent in them. I would guess that using MV’s, even as they are today is >> *safer* for these users than rolling their own. I have seen these patterns >> implemented by people many times, including the “broken in the face of >> concurrency” version. So lets please not try to argue that a casual user >> that does not dig in to the specifics of feature A is going dig in and >> understand the specifics of any other features. So yes, I would prefer my >> bank to use MV’s as they are today over rolling their own, and getting it >> even more wrong. >> >> Now, even given all that, if we want to warn users of the pit falls of using >> MV’s, then lets do that. But lets keep some perspective on how things >> actually get used. >> >> -Jeremiah >> >>> On Oct 3, 2017, at 8:12 PM, Benedict Elliott Smith <_...@belliottsmith.com> >>> wrote: >>> >>> While many users may apparently be using MVs successfully, the problem is >>> how few (if any) know what guarantees they are getting. Since we aren’t >>> even absolutely certain ourselves, it cannot be many. Most of the >>> shortcomings we are aware of are complicated, concern failure scenarios and >>> aren’t fully explained; i.e. if you’re lucky they’ll never be a problem, >>> but some users must surely be bitten, and they won’t have had fair warning. >>> The same goes for as-yet undiscovered edge cases. >>> >>> It is my humble opinion that averting problems like this for just a handful >>> of users, that cannot readily tolerate corruption, offsets any >>> inconvenience we might cause to those who can. >>> >>> For the record, while it’s true that detecting inconsistencies is as much >>> of a problem for user-rolled solutions, it’s worth remembering that the >>> inconsistencies themselves are not equally likely: >>> >>> In cases where C* is not the database of record, it is quite easy to >>> provide very good consistency guarantees when rolling your own >>> Conversely, a global-CAS with synchronous QUORUM updates that are retried >>> until success, while much slower, also doesn’t easily suffer these >>> consistency problems, and is the naive approach a user might take if C* >>> were the database of record >>> >>> Given our approach isn’t uniformly superior, I think we should be very >>> cautious about how it is made available until we’re very confident in it, >>> and we and the community fully understand it. >>> >>> >>>> On 3 Oct 2017, at 18:51, kurt greaves <k...@instaclustr.com> wrote: >>>> >>>> Lots of users are already using MV's, believe it or not in some cases quite >>>> effectively and also on older versions which were still exposed to a lot of >>>> the bugs that cause inconsistencies. 3.11.1 has come a long way since then >>>> and I think with a bit more documentation around the current issues marking >>>> MV's as experimental is unnecessary and likely annoying for current users. >>>> On that note we've already had complaints about changing defaults and >>>> behaviours willy nilly across majors and minors, I can't see this helping >>>> our cause. Sure, you can make it "seamless" from an upgrade perspective, >>>> but that doesn't account for every single way operators do things. I'm sure >>>> someone will express surprise when they run up a new cluster or datacenter >>>> for testing with default config and find out that they have to enable MV's. >>>> Meanwhile they've been using them the whole time and haven't had any major >>>> issues because they didn't touch the edge cases. >>>> >>>> I'd like to point out that introducing "experimental" features sets a >>>> precedent for future releases, and will likely result in using the >>>> "experimental" tag to push out features that are not ready (again). In fact >>>> we already routinely say >=3 isn't production ready yet, so why don't we >>>> just mark 3+ as "experimental" as well? I don't think experimental is the >>>> right approach for a database. The better solution, as I said, is more >>>> verification and testing during the release process (by users!). A lot of >>>> other projects take this approach, and it certainly makes sense. It could >>>> also be coupled with beta releases, so people can start getting >>>> verification of their new features at an earlier date. Granted this is >>>> similar to experimental features, but applied to the whole release rather >>>> than just individual features. >>>> >>>> * There's no way to determine if a view is out of sync with the base table. >>>>> >>>> As already pointed out by Jake, this is still true when you don't use >>>> MV's. We should document this. I think it's entirely fair to say that >>>> users *should >>>> not *expect this to be done for them. There is also no way for a user to >>>> determine they have inconsistencies short of their own verification. And >>>> also a lot of the synchronisation problems have been resolved, undoubtedly >>>> there are more unknowns out there but what MV's have is still better than >>>> managing your own. >>>> >>>>> * If you do determine that a view is out of sync, the only way to fix it >>>>> is to drop and rebuild the view. >>>>> >>>> This is undoubtedly a problem, but also no worse than managing your own >>>> views. Also at least there is still a way to fix your view. It certainly >>>> shouldn't be as common in 3.11.1/3.0.15, and we have enough insight now to >>>> be able to tell when out of sync will actually occur, so we can document >>>> those cases. >>>> >>>>> * There are liveness issues with updates being reflected in the view. >>>> >>>> What specific issues are you referring to here? The only one I'm aware of >>>> is deletion of unselected columns in the view affecting out of order >>>> updates. If we deem this a major problem we can document it or at least put >>>> a restriction in place until it's fixed in CASSANDRA-13826 >>>> <https://issues.apache.org/jira/browse/CASSANDRA-13826> >>>> >>>> >>>> In this case, 'out of sync' means 'you lost data', since the current design >>>>> + repair should keep things eventually consistent right? >>>> >>>> I'd like Zhao or Paulo to confirm here but I believe the only way you can >>>> really "lose data" (that can't be repaired) here would be partition >>>> deletions on massively wide rows in the view that will not fit in the >>>> batchlog (256mb/max value size) as it currently stands. Frankly this is >>>> probably an anti-pattern for MV's at the moment anyway and one we should >>>> advise against. >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
